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

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

Addy Osmani

Barry Pollard

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

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

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

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

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

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

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

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

הערה: כדי לקבל סקירה חזותית של חלק מהתוכן שמופיע במדריך הזה, אפשר לצפות בסרטון 'אופטימיזציה לפי נתונים בסיסיים על חוויית השימוש באינטרנט' מ-Google I/O 2020:

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

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

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

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

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

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

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

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

בדוגמה הזו, מערכת CrUX מודדת ערך CLS גבוה בהרבה מזה של Lighthouse.

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

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

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

אבחון מפורט של CLS ב-Lighthouse.

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

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

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

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

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

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

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

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

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

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

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

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

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

הערה: פתרונות RUM שמודדים את CLS בשטח, כולל הספרייה web-vitals, עשויים להציג הבדלים בנתוני CrUX, כפי שמוסבר במאמר למה נתוני CrUX שונים מנתוני ה-RUM שלי? באופן ספציפי, אי אפשר למדוד CLS שמתרחש ב-iframes באמצעות ממשקי API של אינטרנט, אבל הוא גלוי למשתמש ולכן נכלל ב-CrUX. לכן, למרות שנתוני השדה יכולים להיות יקרים מפז לזיהוי בעיות ב-CLS, חשוב לזכור שהם עשויים להיות חלקיים בתרחישים מסוימים.

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

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

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

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

תמונות ללא ציון רוחב וגובה.

תמונות עם רוחב וגובה שצוינו.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אנימציות

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

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

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

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

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

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

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

סיכום

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