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

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

Addy Osmani

Barry Pollard

תאריך פרסום: 5 במאי 2020, עדכון אחרון: 7 בפברואר 2025

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

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

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

ערכי CLS טובים הם מתחת ל-0.1, ערכים גרועים הם מעל 0.25 וכל ערך שביניהם מצריך שיפור — ערכי CLS טובים הם 0.1 ומטה. ערכים נמוכים הם מעל 0.25.

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

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

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

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

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

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

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

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

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

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

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

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

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

זיהוי בעיות שקשורות ל-CLS של טעינת דף

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

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

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

רשומות של שינוי פריסה מוצגות בחלונית הביצועים של כלי הפיתוח ל-Chrome. — אחרי שמקליטים נתונים חדשים בכרטיסייה Performance (ביצועים), מסלול התוצאות **Layout Shifts** (שינויים בפריסה) מתמלא בפסים סגולים שמציגים `Layout Shift` אשכולות. כשלוחצים על סמל היהלום, מוצגת אנימציה של השינוי ופרטים בחלונית **סיכום**.

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

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

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

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

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

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

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

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

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

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

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

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

מדידת רכיבי CLS בשטח

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

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

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

סיבות נפוצות ל-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 הוא 360px, הרוחב הוא ‎360 x (16 / 9) = 640px
אם הרוחב של 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 בקטע Styles בחלונית Element:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דוגמאות לטעינת תוכן דינמי בלי לגרום לשינויים לא צפויים בפריסה, מ-Twitter ומאתר Chloé — דוגמאות לטעינה של תוכן דינמי בלי לגרום לשינויי פריסה לא צפויים. מימין: תוכן בפיד בשידור חי נטען בטוויטר. משמאל: דוגמה ללחצן 'טעינת עוד מוצרים' באתר של 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" בלבד, המערכת משתמשת בגופן ברירת המחדל, שהוא Times ב-Chrome – גופן עם תגים שמתאים פחות מגופן ברירת המחדל 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 הכולל של האתר, כדאי לקרוא את המדריך ל-bfcache ולקבל פרטים נוספים על בדיקה וזיהוי של בעיות שמונעות את השימוש ב-bfcache.

סיכום

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