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

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

Addy Osmani

Barry Pollard

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

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

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

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

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

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

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

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

הערה: לסקירה ויזואלית של חלק מהתוכן שמוצג במדריך הזה, כדאי לצפות בסרטון על Optimize for Core Web Vitals מ-Google I/O 2020:

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

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

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

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

ההשפעה של Lighthouse 6.0 של הגדרת מידות תמונה על CLS.

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

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

סיכום

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