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

לומדים איך להימנע משינויים פתאומיים בפריסה כדי לשפר את חוויית המשתמש

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

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

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

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

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

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

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

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

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

השוואה בין CLS בכלים לשיעור Lab

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

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

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

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

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

זיהוי בעיות שקשורות ל-CLS

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

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

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

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

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

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

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

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

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

מדידת רכיבי CLS בשדה

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

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

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

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

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

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

היסטוריה של מאפייני width ו-height בתמונות

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

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

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

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

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

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

כאן נכנסים לתמונה יחס הגובה-רוחב. יחס גובה-רוחב של תמונה הוא היחס בין הרוחב לבין הגובה שלה. מקובל לראות שני מספרים שמופרדים בנקודתיים (לדוגמה, 16:9 או 4:3). ביחס גובה-רוחב של x:y, התמונה היא ברוחב של x יחידות ובגובה של y.

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

• אם הגובה של puppy.jpg הוא 360 פיקסלים, הרוחב הוא 360 x (16 / 9) = 640 פיקסלים
• אם הרוחב של puppy.jpg הוא 640 פיקסלים, הגובה הוא 640 x (9 / 16) = 360px

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

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

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

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

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

הפעולה הזו מחשבת יחס גובה-רוחב שמבוסס על המאפיינים width ו-height לפני שהתמונה נטענה. הוא מספק את המידע הזה בתחילת חישוב הפריסה. ברגע שמגדירים שהרוחב של התמונה הוא מסוים (לדוגמה width: 100%), יחס הגובה-רוחב משמש לחישוב הגובה.

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

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

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

החלק 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 ופוסטים ברשתות החברתיות. עם זאת, לרוב ווידג'טים אלה לא מודעים לגודל התוכן שלהם לפני שהם נטענים. כתוצאה מכך, פלטפורמות שמציעות הטמעות לא תמיד שומרות מקום לווידג'טים, מה שגורם לשינויים בפריסה כשהם נטענים בסוף.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אנימציות

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

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

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

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

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

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

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

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

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

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

כדי לצמצם את ה-CLS, יש לוודא שהדפים עומדים בדרישות לשמירה במטמון לדף הקודם/הבא

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

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

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

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

כשהשקנו את הגרסה הזו ב-Chrome, ראינו שיפורים משמעותיים ב-CLS.

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

סיכום

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