אופטימיזציה של Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) הוא אחד משלושת המדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר. כדי למדוד את האמינות של תוכן, המערכת משלבת בין כמות התוכן הגלוי שהשתנה באזור התצוגה למרחק של הרכיבים המושפעים.

שינויים בפריסה עלולים להסיח את דעת המשתמשים. דמיינו שהתחלתם לקרוא מאמר כאשר כל האלמנטים פתאומיים זזים בדף, הופכים אתכם והם דורשים מכם למצוא שוב את מקומכם. זה נפוץ מאוד באינטרנט, גם בזמן קריאת חדשות או כשמנסים ללחוץ על הלחצנים 'חיפוש' או 'הוספה לעגלת הקניות'. חוויות כאלה מרתקות את הצופים וגורמות להם להרגיש מתסכלים. בדרך כלל הם נגרמים כאשר רכיבים גלויים מאולצים לזוז, כי רכיב אחר נוסף פתאום לדף או שגודלו השתנה.

כדי לספק חוויית משתמש טובה, ערך ה-CLS באתרים חייב להיות 0.1 או פחות ל-75% לפחות מהביקורים בדפים.

בשונה מהדוח בנושא מדדי ליבה לבדיקת חוויית המשתמש באתר, שהם ערכים מבוססי זמן שנמדדים בשניות או באלפיות השנייה, ציון ה-CLS הוא ערך ללא יחידה שמבוסס על חישוב של כמות התוכן המשתנה והמרחק.

במדריך הזה נסביר על אופטימיזציה של הסיבות הנפוצות לשינויים בפריסה.

הסיבות הנפוצות ביותר ל-CLS נמוך הן:

• תמונות ללא מידות.
• מודעות, הטמעות ומסגרות iframe ללא מאפיינים.
• תוכן שהוחדר באופן דינמי, כמו מודעות, הטמעות ומסגרות iframe, ללא מימדים.
• גופני אינטרנט.

הסבר על הגורמים לשינויים בפריסה

לפני שמתחילים לעיין בפתרונות לבעיות נפוצות ב-CLS, חשוב להבין את דירוג ה-CLS ומאיפה מגיעים השינויים.

CLS בכלים בשיעור מעבדה לעומת שדה

הרבה מפתחים חושבים שה-CLS שנמדד בדוח חוויית המשתמש של Chrome (CrUX) שגוי כי הוא לא תואם ל-CLS שהם מודדים באמצעות Chrome DevTools או כלים אחרים לשיעור ה-Lab. יכול להיות שכלים למעבדה לבדיקת ביצועים באינטרנט, כמו Lighthouse לא יציגו את ה-CLS המלא של דף, כי בדרך כלל הם מבצעים טעינה פשוטה של הדף כדי למדוד מדדים מסוימים של ביצועי האתר ולספק הנחיות מסוימות. עם זאת, הליכי עבודה של משתמשי Lighthouse מאפשרים לבצע מדידה מעבר לביקורת של טעינת דפים שמוגדרת כברירת מחדל).

CrUX הוא מערך הנתונים הרשמי של תוכנית Web Vitals. המדד 'CLS' מודד את משך החיים המלא של הדף, ולא רק במהלך טעינת הדף הראשונית שבדרך כלל מודדים בכלי ה-Lab.

תנודות בפריסה הן נפוצות מאוד במהלך טעינת הדף, כי אז המערכת מאחזרת את כל המשאבים הנדרשים כדי לעבד את הדף, אבל שינויים בפריסה יכולים להתרחש גם אחרי הטעינה הראשונית. תנודות רבות לאחר הטעינה מתרחשות כתוצאה מאינטראקציה עם משתמש, ולכן הן לא נכללות בציון ה-CLS. כל עוד הם מתרחשים תוך 500 אלפיות השנייה מהאינטראקציה הזו, הם נספרים כשינויים צפויים.

עם זאת, שינויים לא צפויים לאחר הטעינה עשויים להיכלל כאשר אין אינטראקציה מתאימה – לדוגמה, אם תוכן שנטען בעצלנות נטען במלואו בזמן שהמשתמש גולל בדף. סיבות נפוצות אחרות ל-CLS לאחר טעינה מגיעות מאינטראקציות בין מעברים, למשל ב-Single Page Apps, שנמשכות יותר מתקופת החסד של 500 אלפיות השנייה.

ב-PageSpeed Insights מוצגים נתוני ה-CLS שהשפיעו על המשתמשים מכתובת URL בקטע 'מה המשתמשים האמיתיים שלך חווים', וגם את ה-CLS של העומסים בשיעור ה-Lab בקטע 'אבחון בעיות בביצועים'. ההבדלים בין הערכים האלה צפויים להיות תוצאה של CLS לאחר הטעינה.

זיהוי בעיות בטעינת CLS

אם דירוגי ה-CLS של CrUX ו-Lighthouse דומים ב-PageSpeed Insights, המשמעות היא בדרך כלל שמערכת Lighthouse זיהתה בעיית CLS בטעינה. במקרה כזה, מערכת Lighthouse יכולה לספק שתי ביקורות כדי לקבל מידע נוסף: אחת לתמונות שגורמות ל-CLS בגלל חסר רוחב וגובה, ואחת לכל הרכיבים שהשתנו במהלך טעינת הדף יחד עם התרומה שלהם ל-CLS. על מנת לראות את הביקורות האלה, אפשר לסנן אותן כמו בתמונה הבאה:

בחלונית הביצועים בכלי הפיתוח מודגשים גם השינויים בפריסה בקטע Experience. התצוגה Summary של רשומת Layout Shift כוללת את ציון ה-CLS וגם שכבת-על מלבנית שבה מוצגים האזורים המושפעים. הן מועילות במיוחד לזיהוי בעיות ב-CLS עומסות, כי הן מאפשרות לשכפל את חוויית המשתמש בעזרת פרופיל ביצועים בטעינה מחדש.

זיהוי בעיות ב-CLS לאחר הטעינה

מחלוקת בין תוצאות ה-CLS של CrUX ו-Lighthouse של Lighthouse בדרך כלל מצביעה על CLS לאחר הטעינה. קשה לעקוב אחר שינויים כאלה ללא נתוני שטח. מידע נוסף על איסוף נתוני שדות זמין במאמר מדידת רכיבי CLS בשדה.

אפשר להשתמש בתוסף Web Vitals ל-Chrome כדי לעקוב אחר ה-CLS בזמן אינטראקציה עם דף, בתצוגה עילית או במסוף לצד פרטים על הרכיבים שהשתנו.

במקום להשתמש בתוסף, אפשר לגלוש בדף האינטרנט תוך כדי תיעוד של שינויי פריסה באמצעות 'צפייה בביצועים' שהודבקה במסוף.

לאחר הגדרת מעקב אחר משמרות, אפשר לנסות לשכפל בעיות ב-CLS לאחר הטעינה. בדרך כלל נתוני CLS מתרחשים כשהמשתמש גולל בדף, כשתוכן שנטען בהדרגה נטען במלואו בלי מקום ששמור לו. תזוזה של תוכן כשהמשתמש מחזיק את הסמן מעליו, היא סיבה נפוצה נוספת ל-CLS לאחר הטעינה. תזוזה בתוכן במהלך כל אחת מהאינטראקציות האלה נחשבת כבלתי צפויה, גם אם היא מתרחשת תוך 500 אלפיות שנייה.

מידע נוסף זמין במאמר ניפוי באגים בתנודות בפריסה.

אחרי שתזהו את הסיבות הנפוצות ל-CLS, תוכלו גם להשתמש במצב זרימה של המשתמש בטווח הזמן של Lighthouse כדי לוודא ששינויים בפריסה לא פוגעים בתהליכי העבודה האופייניים של המשתמשים.

מודדים רכיבי CLS בשדה

מעקב אחר ה-CLS בשדה יכול לעזור לך לקבוע את הנסיבות שבהן ה-CLS מתרחש ולצמצם את הסיבות האפשריות. כמו רוב הכלים לשיעור ה-Lab, גם כלי השטח מודדים רק את הרכיבים שהשתנו, אבל בדרך כלל מספק מספיק מידע כדי לזהות את הגורם. אפשר גם להשתמש במדידות שדה CLS כדי לקבוע אילו בעיות הכי חשובות לפתרון.

בספרייה web-vitals יש פונקציות שיוך (Attribution) שמאפשרות לכם לאסוף את המידע הנוסף הזה. מידע נוסף זמין במאמר ניפוי באגים של ביצועים בשדה. ספקי RUM אחרים התחילו גם לאסוף ולהציג את הנתונים האלה באופן דומה.

סיבות נפוצות ל-CLS

בקטע הזה מפורטות כמה מהסיבות הנפוצות יותר ל-CLS ואסטרטגיות להימנעות מהן.

תמונות ללא מידות

חשוב לכלול תמיד את מאפייני הגודל width ו-height בתמונות וברכיבי הווידאו, או לשריין את המקום הנדרש באמצעות CSS aspect-ratio. כך הדפדפן מקצה את השטח הנכון למסמך בזמן טעינת התמונה.

width,‏ height,‏ aspect-ratio

בימים הראשונים של האינטרנט, מפתחים הוסיפו את המאפיינים width ו-height לתגי <img> שלהם כדי להבטיח שהוקצה לדף מספיק מקום לפני שהדפדפן התחיל לאחזר תמונות. כך תצמצם את ההזרמה החוזרת והפריסה מחדש.

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

width ו-height בדוגמה הזו לא כוללים יחידות. מידות ה "פיקסלים" האלה יבטיחו שהדפדפן ישמור אזור של 640x360. התמונה תמתח כדי להתאים לשטח הזה, גם אם המידות האמיתיות תאמו לו.

כשהשקנו את עיצוב האתר הרספונסיבי, המפתחים התחילו להשתמש ב-CSS כדי לשנות את הגודל של התמונות, במקום את width ו-height:

img {
  width: 100%; /* or max-width: 100%; */
  height: auto;
}

עם זאת, מכיוון שלא צוין גודל תמונה, לא ניתן להקצות לה מקום עד שהדפדפן מתחיל להוריד אותה ולקבוע את המידות שלה. במהלך טעינת התמונות, הטקסט זז למטה כדי לפנות מקום להן ויוצר חוויית משתמש מבלבלת ומתסכלת.

שיטות מומלצות להגדרת מידות התמונה

מכיוון שדפדפנים מודרניים מגדירים את יחס הגובה-רוחב של תמונות כברירת מחדל על סמך המאפיינים width ו-height של התמונה, ניתן למנוע שינויים בפריסה על ידי הגדרת המאפיינים האלה בתמונה והוספת ה-CSS הקודם לגיליון הסגנון.

<!-- set a 16:9 aspect ratio as 640x360 pixels -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

לאחר מכן הדפדפן מוסיף ברירת מחדל ליחס גובה-רוחב על סמך המאפיינים הקיימים width ו-height של הרכיב, כדי לקבוע כמה מקום לשמור לתמונה בתחילת חישובי הפריסה.

מכיוון שהדפדפנים העיקריים מחשבים יחסי גובה-רוחב שמוגדרים כברירת מחדל במהלך עיבוד ה-HTML, כל דפדפן מציג את הערך באופן קצת שונה. (לפרטים על הסיבות לכך, ראו טיפים להצגה לגבי רוחב וגובה).

לדוגמה, Chrome מציג יחסי גובה-רוחב כמו זה בקטע סגנונות בחלונית Element:

img[Attributes Style] {
  aspect-ratio: auto 640 / 360;
}

Safari מתנהג באופן דומה באמצעות מקור סגנון של מאפייני HTML. האפשרות aspect-ratio המחושבת לא מוצגת ב-Firefox בחלונית Inspector, אבל כן משתמש בו לפריסה.

החלק auto של הקוד הקודם חשוב, כי הוא גורם למידות התמונה לעקוף את יחס הגובה-רוחב שמוגדר כברירת מחדל אחרי הורדת התמונה. אם מידות התמונה שונות, הדבר עדיין גורם לשינויי פריסה מסוימים אחרי העלאת התמונה, אבל הדבר מבטיח שיחס הגובה-רוחב של התמונה ימשיך להיות זמין, למקרה שה-HTML שגוי. גם אם יחס הגובה-רוחב בפועל שונה מברירת המחדל, זה עדיין גורם לשינוי קטן יותר בפריסה מגודל ברירת המחדל 0x0 של תמונה ללא מידות.

כדי לקבל סקירה מפורטת ויסודית ביחסי גובה-רוחב ובתפיסת העולם של שימוש בתמונות רספונסיביות, קראו את המאמר טעינה של דפים ללא ספאם עם יחסי גובה-רוחב של מדיה.

אם התמונה נמצאת בקונטיינר, אפשר להשתמש ב-CSS כדי לשנות את הגודל של התמונה לרוחב המאגר. הגדרנו את height: auto; על מנת להימנע משימוש בערך קבוע של גובה התמונה.

img {
  height: auto;
  width: 100%;
}

מה לגבי תמונות רספונסיביות?

בעבודה עם תמונות רספונסיביות, srcset מגדיר את התמונות שאתם מאפשרים לדפדפן לבחור בין ואת הגודל של כל תמונה, כדי להבטיח שאפשר יהיה להגדיר <img> מאפייני רוחב וגובה. צריך להשתמש באותו יחס גובה-רוחב לכל תמונה.

<img
  width="1000"
  height="1000"
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  alt="Puppy with balloons"
/>

גם יחסי הגובה-רוחב של התמונות יכולים להשתנות בהתאם לכיוון האומנות שלכם. לדוגמה, ייתכן שתרצו להוסיף תמונה חתוכה של תמונה לאזורי תצוגה צרים ולהציג את התמונה המלאה במחשב:

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>

Chrome, Firefox ו-Safari תומכים עכשיו בהגדרה של width ו-height בצאצאים של source של הרכיב picture:

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width=480 height=400/>
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" width=800 height=400/>
  <img src="puppy-800w.jpg" alt="Puppy with balloons" width=800 height=400/>
</picture>

מודעות, הטמעות ותוכן אחר שנטען מאוחר

תמונות הן לא סוג התוכן היחיד שיכול לגרום לשינויים בפריסה. מודעות, הטמעות, מסגרות iframe ותכנים אחרים שמוחדרים באופן דינמי יכולים לגרום לתוכן שמופיע אחרי תזוזה למטה, ולהגדיל את ה-CLS.

מודעות הן אחד הגורמים המשמעותיים ביותר לשינויים בפריסה באינטרנט. לעתים קרובות, רשתות מודעות ובעלי אתרים תומכים בגדלים של מודעות דינמיות, ומודעות גדולות יותר מניבות לעתים קרובות יותר הכנסות ממודעות קטנות יותר. עם זאת, מודעות שנטענות בפתאומיות ודוחפות תוכן גלוי למטה בדף פוגעות בחוויית המשתמש.

ווידג'טים שניתנים להטמעה מאפשרים לך לכלול תוכן אינטרנט נייד בדף, כמו סרטונים מ-YouTube, מפות ממפות Google ופוסטים במדיה חברתית. עם זאת, בדרך כלל הווידג'טים האלה לא מודעים לגודל של התוכן שלהם לפני שהם נטענים. כתוצאה מכך, פלטפורמות שמציעות הטמעות לא תמיד שומרות מקום לווידג'טים, וזה גורם לשינויי פריסה כשהם נטענים בסוף.

הטכניקות להתמודדות עם הגורמים האלה דומות כולן. ההבדלים העיקריים הם במידת השליטה שיש לך על התוכן שנוסף. צדדים שלישיים, כמו שותפי מודעות, לעתים קרובות לא יספקו לכם מידע שימושי על התוכן שנוסף, או על שליטה בשינויים בפריסה של המודעות שהטמענו.

שמור מקום לטעינה מאוחרת של תוכן

כשמציבים תוכן שנטען מאוחר יותר בזרימת התוכן, אפשר למנוע שינויים בפריסה על ידי שמירת מקום עבורם בפריסה הראשונית.

זה יכול להיות פשוט הוספת סגנון min-height כדי לשריין מקום, או, במקרה של תוכן רספונסיבי כמו מודעות, שימוש במאפיין ה-CSS החדש aspect-ratio באופן דומה לדפדפנים שמשתמשים בו באופן אוטומטי לתמונות.

יכול להיות שתצטרכו להביא בחשבון הבדלים קלים בגדלים של מודעות או placeholders בגורמי צורה שונים באמצעות שאילתות מדיה.

בתוכן שאין לו גובה קבוע, כמו מודעות, ייתכן שלא תוכל לשריין את השטח המדויק שנדרש כדי למנוע לחלוטין את שינוי הפריסה. אם מוצגת מודעה קטנה יותר, בעל האתר יכול לעצב מאגר גדול יותר כדי למנוע שינויים בפריסה, או לבחור את הגודל הסבירות ביותר למיקום המודעה על סמך נתונים היסטוריים. החיסרון של הגישה הזו הוא שהיא מגדילה את כמות השטח הריק בדף.

במקום זאת, ניתן לך להגדיר את הגודל הראשוני לגודל הקטן ביותר שבו ייעשה שימוש, ולקבל רמה מסוימת של התאמה לתוכן גדול יותר. כפי שהוצע קודם לכן, השימוש ב-min-height מאפשר לרכיב ההורה לגדול לפי הצורך תוך צמצום ההשפעה של שינויי פריסה, בהשוואה לגודל ברירת המחדל של 0 פיקסלים של רכיב ריק.

כדי למנוע כיווץ של השטח השמור, כדאי להציג placeholder אם, לדוגמה, לא הוחזרה מודעה. הסרת הרווח שהוקצה לרכיבים יכולה לגרום ל-CLS באותה מידה כמו הוספת תוכן.

יש למקם תוכן שנטען מאוחר יותר באזור התצוגה

תוכן שמוחדר באופן דינמי קרוב יותר לחלק העליון של אזור התצוגה גורם בדרך כלל לשינויי פריסה גדולים יותר מאשר תוכן שמוחדר נמוך יותר באזור התצוגה. עם זאת, החדרת תוכן במקום כלשהו באזור התצוגה עדיין גורמת לשינוי מסוים. אם אתם לא יכולים לשריין מקום לתוכן שהוחדר, מומלץ להציב אותו מאוחר יותר בדף כדי לצמצם את ההשפעה.

תוכן מודעת באנר בשכבת-על

מודעות באנר וטפסים שמופיעות באופן בלתי צפוי בדף הם סיבה נפוצה נוספת לשינויים לא צפויים בפריסה.

אם אין לכם אפשרות לשריין מקום לתוכן מהסוג הזה, אפשר להשתמש במקום זאת בשכבת-על מעל לתוכן קיים, כך שלא יהיה חלק מזרימת המסמך. כדי לדעת מתי כדאי להשתמש בגישה הזו, ראו שיטות מומלצות להודעות בנושא קובצי cookie.

אפשר לאינטראקציה של המשתמש להפעיל שינויים צפויים בפריסה

במקרים מסוימים, הוספת תוכן באופן דינמי היא חלק חשוב מחוויית המשתמש, למשל, כשטוענים עוד מוצרים לרשימה של פריטים או כשמעדכנים תוכן בפיד פעיל. יש כמה דרכים למנוע שינויים לא צפויים בפריסה במקרים האלה:

• החלפת תוכן ישן בתוכן חדש בתוך מאגר בגודל קבוע, או שימוש בקרוסלה והסרת התוכן הישן לאחר המעבר. אל תשכחו להשבית את כל הקישורים ואמצעי הבקרה עד לסיום ההעברה, כדי למנוע קליקים או הקשות בטעות בזמן טעינת התוכן החדש.
• אפשרו למשתמש להתחיל את הטעינה של תוכן חדש, לדוגמה באמצעות הלחצן Load more או רענן, כך שהשינוי לא מפתיע. מומלץ לאחזר מראש את התוכן החדש לפני האינטראקציה של המשתמש, כדי שהוא יופיע באופן מיידי. חשוב לזכור, שינויי פריסה בתוך 500 אלפיות השנייה של קלט משתמשים לא נספרים ב-CLS.
• טעינת התוכן בצורה חלקה מחוץ למסך והוספת שכבת-על של הודעה למשתמש לגבי הזמינות (לדוגמה, באמצעות הלחצן גלילה למעלה).

אנימציות

אם תבצעו שינויים בערכים של מאפייני ה-CSS, יכול להיות שהדפדפן שלכם יגיב לשינויים האלה. ערכים מסוימים, כמו box-shadow ו-box-sizing, מפעילים פריסה מחדש, צבע ורכיב. שינוי המאפיינים top ו-left גורם גם לשינויי פריסה, גם כשהרכיב שמועבר נמצא בשכבה משלו. הימנעו מאנימציה באמצעות המאפיינים האלה.

אפשר לשנות מאפייני CSS אחרים בלי להפעיל פריסות מחדש. למשל, שימוש באנימציות transform כדי לתרגם, לשנות את הגודל, לסובב או להטות רכיבים.

אנימציות מורכב שמשתמשות ב-translate לא יכולות להשפיע על אלמנטים אחרים, ולכן לא כדאי לספור אותן ב-CLS. גם אנימציות לא משולבות לא גורמות לפריסה מחדש. למידע נוסף על מאפייני ה-CSS שמפעילים שינויים בפריסה, אפשר לקרוא את המאמר אנימציות בעלות ביצועים גבוהים.

גופני אינטרנט

ההורדה והעיבוד של גופני אינטרנט בדרך כלל מטופלות באחת משתי דרכים, לפני ההורדה של גופן האינטרנט:

• הגופן החלופי מוחלף בגופן האינטרנט באמצעות Flash של טקסט ללא עיצוב (FOUT).
• הטקסט "בלתי נראה" מוצג באמצעות הגופן החלופי עד שגופן אינטרנט יהיה זמין והטקסט יהיה גלוי, באמצעות Flash של טקסט בלתי נראה (FOIT).

שתי הגישות יכולות לגרום לשינויים בפריסה. גם אם הטקסט בלתי נראה, הוא עדיין פריסה בגופן החלופי. לכן, כשגופן האינטרנט נטען, גוש הטקסט והתוכן שמסביב זזים באותו אופן כמו הגופן שמוצג.

אפשר להיעזר בכלים הבאים כדי למזער את היסט הטקסט הזה:

• font-display: optional גורם לשימוש בגופן האינטרנט רק אם הוא זמין בזמן הפריסה הראשונית.
• השתמש בגופנים חלופיים דומים לגופן האינטרנט. לדוגמה, אם תשתמשו ב-font-family: "Google Sans", sans-serif;, הדפדפן ישתמש בגופן החלופי sans-serif בזמן הטעינה של "Google Sans". אם לא מציינים גופן חלופי (באמצעות font-family: "Google Sans" בלבד), Chrome יכול להשתמש בגופן serif שמוגדר כברירת מחדל, וזה התאמה גרועה יותר.
• כדאי לצמצם את הבדלי הגודל בין הגופן החלופי לבין גופן האינטרנט באמצעות ממשקי ה-API החדשים של size-adjust, ascent-override, descent-override ו-line-gap-override. פרטים נוספים זמינים במאמר חלופות משופרות של גופנים.
• Font Charge API יכול לקצר את זמן הטעינה של הגופנים.
• יש לטעון גופני אינטרנט קריטיים בהקדם האפשרי באמצעות <link rel=preload>. יש סיכוי גבוה יותר שגופן שנטען מראש יהיה מוכן לצבע הראשון ולא יגרום לשינוי בפריסה.

מידע נוסף זמין במאמר שיטות מומלצות לשימוש בגופנים.

איך מתאימים את הדפים לשמירה במטמון לדף הקודם/הבא

שיטה יעילה מאוד לשימור ציוני CLS נמוכים היא לוודא שדפי האינטרנט עומדים בדרישות לשמירה של מטמון לדף הקודם/הבא (bfcache).

במטמון לדף הקודם/הבא נשמרים דפים בזיכרון של הדפדפן למשך זמן קצר אחרי שמנתם לנווט, כך שאם תחזרו אליהם, הם ישוחזרו בדיוק כפי שעזבתם. המשמעות היא שהדף שנטען במלואו זמין באופן מיידי, ללא שינויים שעלולים להתרחש בזמן שהדף נטען.

זה עדיין יכול לגרום לשינויים בפריסה של הטעינה הראשונית, אבל היא מאפשרת למשתמשים להימנע מלראות את אותם שינויי פריסה שוב ושוב. כך מפחיתים את ההשפעה של שינויים בפריסה שייתכן שנתקלתם בהם ושקשה לפתור בדרכים אחרות.

ניווטים קדימה ואחורה נפוצים באתרים רבים, למשל כשחוזרים לדף תוכן, לדף של קטגוריה או לתוצאות חיפוש.

המטמון לדף הקודם משמש כברירת מחדל בכל הדפדפנים, אבל חלק מהאתרים לא עומדים בדרישות ממגוון סיבות. במאמר בנושא bfcache מוסבר איך בודקים ומזהים בעיות שמונעות את השימוש במטמון לדף הקודם/הבא.