index.php

LCP – טעינה והצגה של רכיב התוכן הגדול ביותר

LCP – טעינה והצגה של רכיב התוכן הגדול ביותר

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

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

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

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

מה זה LCP?

מדד ה-LCP מציג את זמן הטעינה וההצגה של הרכיב הגדול ביותר על גבי המסך.

מה נחשב לציון LCP טוב?

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

אילו רכיבים בדף נלקחים בחשבון בתהליך החישוב?

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

·      רכיבי תמונה הנמצאים בתגית <img>

·      רכיבי תמונה <img> בתוך <svg>

·      רכיבי סרטון בתוך <video> (כאשר נעשה שימוש בתמונה הראשית של הסרטון)

·      רכיבי תמונת הרקע הנטענים באמצעות פונקציית url() – זאת בניגוד לאפשרות הקיימת בתוך ה- CSS Gradient.

·      רכיבים ברמת הבלוק, הכוללים תוכן גרפי המוטמע בתוך הקוד (למשל, הוספה של צבע רקע לפסקה או לשורה בתוך ה-CSS בקוד).

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

כיצד נקבע גודל הרכיב בדף?

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

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

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

באופן גורף עבור כל הרכיבים בדף – נתוניPadding  (מרווח), Margin (שוליים) ו-Border (מסגרת סביב הרכיב) בקובץ העיצוב (CSS) לא ישוקללו.

________________________________________________

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

מתי ההצגה של רכיב התוכן הגדול ביותר (LCP) מדווחת?

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

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

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

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

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

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

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

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

זמן הטעינה מול זמן העיבוד

בשל שיקולי אבטחה, חותמת זמן העיבוד של התמונה לא נחשפת למשתמש בתמונות המגיעות ממקור נפרד ללא כותרת של Timing-Allow-Origin. במקום זאת, ניתן לצפות רק בזמן הטעינה (היות ונתון זה פתוח לקהל הרחב באמצעות מגוון רחב של ממשקי API מקוונים).

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

כיצד מטופלים פריסת הרכיבים בדף וגודלם?

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

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

בכל מקרה (כפי שהוזכר לעיל), הרכיבים שהוסרו מה-DOM לא ילקחו בחשבון אם מקור התמונה שלהם השתנה.

דוגמאות

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

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

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

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

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

כיצד למדוד LCP?

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

מדידה בתנאי שטח

·       דו"ח חוויית המשתמש של כרום – Chrome User Experience Report

·       תובנות PageSpeed – PageSpeed Insights

·       דו"ח מדדי הליבה ברשת – Search Console (Core Web Vitals report)

מדידה בתנאי מעבדה

·       כלי הפיתוח של כרום – Chrome DevTools

·       פלטפורמת המגדלור – Lighthouse

·       אתר WebPageTest

מדידת LCP באמצעות ג'אווה סקריפט

הדרך הקלה ביותר למדוד LCP (כמו גם את כל מדדי הליבה ברשת) היא באמצעות ספריית הג'אווה סקריפט web-vitals, המאגדת את כל המורכבות הכרוכה במדידת ה-LCP לתוך פונקציה אחת:

import {getLCP} from 'web-vitals';

// Measure and log the current LCP value,
// any time it's ready to be reported.
getLCP(console.log);

כדי לחשב בצורה ידנית את הLCP, ניתן להשתמש ב-API של Largest Contentful Paint. הדוגמה הבאה מציגה כיצד ניתן ליצור מופע של PerformanceObserver שיאזין לכל הרשומות של Largest-Contentful-paint ויתעד את ערך ה LCP לתוך הקונסול: (יש להעתיק את הקוד המופיע במקור).

אין לדווח על LCP אם הדף נטען בלשונית ברקע. הקוד מעלה מטפל במקרה זה בצורה חלקית, אך אינו מבצע פעולה זו בצורה מושלמת, משום שהדף עשוי להיות נסתר ולאחר מכן להופיע לפני שהקוד הזה רץ בפועל. בפתרון לבעיה זו נדון בהרחבה במפרט הטכני של ה-API המטפל בנראות הדף – Page Visibility API spec.

מה אם הרכיב הגדול ביותר בדף אינו הרכיב המשמעותי ביותר?

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

כיצד ניתן לבצע אופטימיזציה ל-LCP?

LCP מושפע בעיקר מארבעה גורמים:

·       זמן תגובה ארוך ואיטי של השרת

·       ג'אווה סקריפט וקובץ סטיילינג (CSS) המעקבים או מונעים את עיבוד הדף

·       זמן הטעינה של קבצי מקור

·       עיבוד בצד הלקוח

 

 

הסטת פריסה מצטברת – CLS

הסטת פריסה מצטברת – CLS

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

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

מהו ציון CLS טוב?
כדי להעניק חוויית משתמש חיובית בעלי אתרים צריכים לשאוף לציון הנמוך מ-0.1. כדי לוודא שמצליחים להגיע לציון זה עבור מרבית המשתמשים, סף המדידה הנכון הוא האחוזון ה-75 בנתוני טעינת הדף, הן בסגמנט של משתמשי מכשירים ניידים והן בסגמנט של משתמשי מחשב.
מבט עומק בהסטות פריסה
הסטות פריסה מוגדרות באמצעות ה-API Layout Instability API (יציבות הפריסה), המתעדות ומדווחות על רשומות Layout-Shift בכל פעם שרכיב משנה את מיקומו בתצוגה בין שתי נקודות זמן. (למשל, שינוי של מיקומו ביחס לגבול העליון והשמאלי של המסך במיקום ברירת המחדל שלו בתצוגה)
חשוב לשים לב כי הסטות פריסה מתרחשות רק כאשר הרכיב משנה את מיקומו ההתחלתי. אם רכיב נוסף ל-DOM או שרכיב קיים משנה את גודלו, פעולות אלה אינן משוקללות כהסטת פריסה, כל עוד השינוי אינו גורם לרכיבים אחרים המוצגים על המסך לשנות את מיקומם ההתחלתי.
ציון הסטת הפריסה
כדי לחשב את ציון הסטת הפריסה, על הדפדפן לבחון את גודל התצוגה ואת התנועה של רכיבים לא יציבים בתצוגה זו בין שני פריימים שעובדו. ציון הסטת הפריסה הוא מכפלה של ערכים שונים המייצגים תנועה זו: "מרכיב ההשפעה" ו-"מרכיב המרחק" (שניהם מוגדרים בהמשך).
layout shift score = impact fraction * distance fraction
מרכיב ההשפעה

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

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

בדוגמה מעל הממד הגדול ביותר בתצוגה הוא האורך, והרכיב הלא יציב נע בשיעור של 25% של גובה התצוגה. לכן מרכיב המרחק יהיה 0.25.
לסיכום, בדוגמה שציינו מרכיב ההשפעה יהיה 0.75 ומרכיב המרחק יהיה 0.25, לכן ציון הסטת הפריסה יהיה: 0.1875=0.75*0.25
בתחילה, ציון הסטת הפריסה היה מחושב אך ורק על פי מרכיב ההשפעה. מרכיב המרחק נוסף למשוואה כדי לצמצם מקרים שבהם האתר נענש בחומרה בשל הסטות קלות של רכיבים גדולים על המסך.
הדוגמה הבאה ממחישה כיצד הוספה של תוכן לרכיב קיים משפיעה על ציון הסטת הפריסה:

כפתור "”Click Me! נוסף לתצוגה בתחתית הקובייה האפורה עם הטקסט השחור, פעולה זו דוחפת את הקובייה הירוקה עם הטקסט הלבן מטה (הוא נע באופן חלקי אל מחוץ לתצוגה).
בדוגמה זו, הקובייה הירוקה משנה את גודלה, אך נקודת ההתחלה שלה אינו משתנה, לכן במקרה זה לא מדובר ברכיב שאינו יציב.
הכפתור "Click Me!" לא היה קיים קודם לכן ב-DOM, לכן המיקום ההתחלתי שלו אף הוא נותר בעינו ואינו משתנה.
המיקום ההתחלתי של הקובייה הירושה, לעומת זאת, משתנה, אך מאחר והקובייה נעה באופן חלקי אל מחוץ לתצוגה, החלק הנראה לעין אינו נלקח בחשבון בחישוב מרכיב ההשפעה. איחוד השטח הנראה של הקובייה הירוקה בשני הפריימים (המיוצג באמצעות המלבן האדום המקווקו) הוא זהה לשטח של הקובייה הירוקה בפריים הראשון – 50% מהתצוגה. מרכיב ההשפעה הוא 0.5.
מרכיב המרחק מוצג באמצעות החץ הסגול. הקובייה הירוקה נעה בשיעור של 14% מהתצוגה, לכן ערך מרכיב המרחק הוא 0.14. ציון הסטת הפריסה הוא0.07 = 0.5 * 0.14
הדוגמה האחרונה מציגה מצב שבו קיימים שני רכיבים לא יציבים:

בתמונה מעלה, בפריים הראשון מוצגות ארבע תוצאות של בקשה מ-API לקבלת שמות בעלי חיים והצגתם לפי סדר אלף־בית. בפריים השני, נוספות תוצאות לרשימה הממויינת.
האיבר הראשון ברשימה ("חתול") אינו משנה את מיקומו ההתחלתי בין הפריימים, לכן הוא יציב. באותה מידה, האיברים הראשונים ברשימה לא היו נוכחים בתחילה ב-DOM, לכן המיקום הראשוני שלהם אף הוא אינו משתנה. אך, מיקומם של האיברים "כלב", "סוס" ו-"זברה" משתנה ולכן הם מוגדרים כרכיבים שאינם יציבים.
שוב המלבנים האדומים ממחישים את האיחוד בין שטחי הרכיבים הלא יציבים לפני ואחרי השינוי, במקרה זה השינוי הוא בשיעור של 38% משטח התצוגה הכולל. לכן מרכיב ההשפעה יעמוד על 0.38.
החצים מייצגים את המרחק שהרכיבים הלא יציבים נעו ממיקומם ההתחלתי. האיבר "זברה", המיוצג באמצעות החץ הכחול, נע בשיעור הרב ביותר, בשיעור של כ-30% מגובה התצוגה. לכן, מרכיב המרחק בדוגמה זו הוא 0.3.
ציון הסטת הפריסה הוא: 0.1172 = 0.38 * 0.3
הסטות פריסה צפויות מול הסטות פריסה שאינן צפויות
לא כל הסטת פריסה היא שלילית. למעשה, יישומוני רשת רבים משנים לעתים תכונות את מיקומם ההתחלתי של הרכיבים השונים בדף.
הסטת פריסה ביוזמת המשתמש
הסטת פריסה היא שלילית אם המשתמש לא ציפה לכך מראש. מצד שני, הסטות פריסה המתרחשות כתוצאה מאינטראקציה של המשתמש (הקלקה על לינק, לחיצה על כפתור, הקלקת ביטוי בתיבת חיפוש ופעולות נוספות שבוצעו על ידי המשתמש במכוון) הן בדרך כלל תקינות לחלוטין, כל עוד השינוי מתרחש קרוב ככל האפשר לפעולה שבוצעה, כדי שהקשר בין הפעולה לבין שינוי התצוגה יהיה נהיר למשתמש.
למשל, אם אינטראקציה מצד המשתמש מפעילה בקשת רשת העשויה לארוך זמן מה עד שתסתיים, עדיף להקצות שטח כלשהו בדף להצגת מחוון טעינה, זאת כדי להימנע משינוי פריסה מטריד כאשר התגובה לבקשה מסתיימת. אם המשתמש אינו מבין שהחלה טעינה של רכיב כלשהו, או שהוא לא יכול לחוש מתי התוכן שבקש לטעון יהיה מוכן, יתכן והוא ינסה להקליק על רכיב אחר בדף בעודו ממתין, אך רכיב זה עשוי להעלם פתאום מול עיניו המשתאות.
הסטות פריסה המתרחשות 500 מילי־שניות מהרגע שבו תועדה פעולת הזנת קלט אחרון לא יכללו במשוואה. הדבר מתבצע באמצעות סימון המאפיין  hadRecentInput.
הנפשות ומעברים
הנפשות ומעברים המבוצעים בצורה נכונה הם דרך נהדרת לעדכן את הדף מבלי להפתיע את המשתמש. תוכן המשתנה בפתאומיות בצורה בלתי צפויה בדף, ייצור כמעט תמיד חוויית משתמש שלילית. לעומת זאת, תכנים שנעים בהדרגה ובצורה טבעית ממצב אחד למשנהו, יסייעו לעתים קרובות לעזור למשתמשים להבין טוב יותר את המתרחש ויובילו  אותם בין מצב אחד לאחר.
מאפיין ה-CSS "Transform" מאפשר להנפיש רכיבים שונים בדף מבלי לגרום להסטות פריסה:
·      במקום לשנות את המאפיינים של גובה ורוחב (height, hidth), השתמשו בפונקציה transform: scale().
·      כדי להניע רכיבים ממקום למקום בתצוגה המנעו משינוי של המאפיינים:
top, right, bottom או left. במקום זאת השתמשו בפונקציה transform: translate().
כיצד למדוד CLS?
ניתן למדוד CLS בתנאי מעבדה או בתנאי שטח, ובדיקות אלה זמינות באמצעות הכלים הבאים:
זהירות: כלי מדידה בתנאי מעבדה טוענים את הדף בסביבה מלאכותית, ולכן יכולים למדוד הסטות פריסה המתרחשות במהלך טעינת הדף. לכן, ה-CLS המדווח על ידי כלי בדיקה אלה לדף נתון, עשויים להיות נמוכים מחוויית המשתמש של משתמשים אמיתיים בשטח.
מדידה בתנאי שטח
·      דו"ח חוויית המשתמש של כרום – Chrome User Experience Report
·      תובנות PageSpeed – PageSpeed Insights
·      דו"ח מדדי הליבה ברשת – Search Console (Core Web Vitals report)
מדידה בתנאי מעבדה
·      כלי הפיתוח של כרום – Chrome DevTools
·      פלטפורמת המגדלור – Lighthouse
·      אתר WebPageTest
מדידת CLS באמצעות ג'אווה סקריפט
הדרך הקלה ביותר למדוד CLS (כמו גם את כל מדדי הליבה ברשת) היא באמצעות ספריית הג'אווה סקריפט web-vitals, המאגדת את כל המורכבות הכרוכה במדידת ה-CLS לתוך פונקציה אחת:
import {getCLS} from 'web-vitals';
// Measure and log the current CLS value,
// any time it's ready to be reported.
getCLS(console.log);
כדי לחשב בצורה ידנית את ה-CLS, ניתן להשתמש ב-API שלLayout Instability . הדוגמה הבאה מציגה כיצד ניתן ליצור מופע של PerformanceObserver שיאזין לכל הרשומות של layout-shift, ויתעד אותן בקונסול:
// Use a try/catch instead of feature detecting `layout-shift`
// support, since some browsers throw when using the new `type` option.
// https://bugs.webkit.org/show_bug.cgi?id=209216
try {
const po = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log(entry);
}
});
po.observe({type: 'layout-shift', buffered: true});
} catch (e) {
// Do nothing if the browser doesn't support this API.
}
ה-CLS הוא סכום כל הרשומות הפרטניות שלא התרחשו במהלך קבלת הקלט האחרון מהמשתמש. כדי לחשב את ה-CLS יש להצהיר על משתנה שיאחסן את הציון, ולאחר מכן להוסיף אליו כל פעם שמתרחש שינוי פריסה בלתי צפוי.
במקום לדווח על כל שינוי של ה-CLS (העשוי להתרחש לעתים תכופות), מוטב לשמור את ערך ה-CLS הנוכחי ולדווח עליו בכל פעם שמצב מחזור החיים של הדף עובר ל"נסתר":
(להעתיק את בלוק הקוד הארוך כאן)
·       הערה:CrUX  מאגד את נתוני ה-CLS בקבוצות שכל אחת מהן מייצגת חמישה אחוזים, לכן אם התוצאה המתקבלת היא 0.01 היא תיכלל בקבוצה של 0%-5%, לעומת זאת אם התוצאה היא 0.07 היא תיכלל בקבוצה של 5%-10%.
כיצד ניתן לשפר את ה-CLS?
שיפור CLS במרבית האתרים יכול להתבצע באמצעות שמירה על מספר עקרונות מנחים:
·       נסו לכלול תמיד מאפייני גוגל בכל רכיבי התמונה והווידאו באתר, או שימרו את השטח הנדרש לרכיב באמצעות הגדרת יחסי גובה־רוחב בקובץ ה-CSS. באמצעות גישה זו תוכלו להבטיח כי הדפדפן יקצה את השטח המתאים למסמך בזמן שהתמונה נטענת. אפשרות נוספת היא שימוש במאפיין  Feature-Policy: unsized-media  בשורת ה-header  בקוד, מאפיין זה נתמך בחלק מהדפדפנים.
·       לעולם אל תשלבו תוכן חדש מעל תוכן קיים, מלבד במקרים של תגובה לאינטראקציה ביוזמת המשתמש. כך תוכלו להבטיח שהמשתמש יצפה לכל הסטות הפריסה.
·       העדיפו להשתמש בהנפשה מסוג Transform בכל פעם שאתם יוצרים הנפשה למאפיין הגורמים לשינויים בפריסת הדף. הנפישו את המעברים בצורה שתעניק הקשר למעבר ממצב אחד לשני.

שיחת טלפון
צור קשר