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

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

Addy Osmani
Addy Osmani
X GitHub
Barry Pollard

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

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

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

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

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

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

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

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

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

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

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

מפתחים רבים סבורים שה-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 לאחר הטעינה.

צילום מסך של PageSpeed Insights שבו מוצגים נתונים ברמת כתובת ה-URL שמדגישים את ה-CLS האמיתי של המשתמש, והוא גדול משמעותית מ-Lighthouse CLS
בדוגמה הזו, ה-CLS נמדד ב-CrUX גדול בהרבה מאשר ב-Lighthouse.

זיהוי בעיות ב-CLS של טעינה

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

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

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

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

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

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

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

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

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

היסטוריית המאפיינים 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) = 360 פיקסלים

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

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

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

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

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

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

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

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

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

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

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

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

תוכן דינמי ללא מקום שמור.

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

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

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

אנימציות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סיכום

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