בתוך כמה חודשים, אתר החדשות המוביל בבריטניה הצליח לשפר את הערך של CLS ב-75% מהפרמטר ה-percentile ל-250%, מ-0.25 ל-0.1.
האתגר של יציבות חזותית
שינויי פריסה יכולים להיות מאוד מפריעים. ב-Telegraph Media Group (TMG) חשובה במיוחד יציבות חזותית, כי הקוראים משתמשים בעיקר באפליקציות שלנו כדי לצרוך את החדשות. אם הפריסה תשתנה בזמן קריאת מאמר, סביר להניח שהקורא יאבד את המקום שבו הוא עצר. זה יכול להיות חוויה מתסכלת ומסיחת דעת.
מבחינה הנדסית, יכול להיות מאתגר לוודא שהדפים לא זזים ומפריעים לקורא, במיוחד כשחלקים באפליקציה נטענים באופן אסינכרוני ומתווספים לדף באופן דינמי.
ב-TMG יש כמה צוותים שתורמים קוד מצד הלקוח:
- הנדסת ליבה הטמעת פתרונות של צד שלישי כדי לשפר תחומים כמו המלצות תוכן ופרסום תגובות.
- שיווק. מריצים בדיקות A/B כדי להעריך את האינטראקציה של הקוראים עם תכונות או שינויים חדשים.
- פרסום. ניהול בקשות להצגת מודעות ובידינג מראש על מודעות.
- עריכה הטמעת קוד במאמרים כמו ציוצים או סרטונים, וגם ווידג'טים מותאמים אישית (לדוגמה, מעקב אחר מספר הנדבקים בקורונה).
יכול להיות שיהיה קשה לוודא שכל אחד מהצוותים האלה לא יגרום לשינויים קיצוניים בפריסה של הדף. בעזרת המדד Cumulative Layout Shift, שמודד את התדירות שבה הקוראים שלנו נתקלים בבעיה הזו, הצוותים קיבלו תובנות נוספות לגבי חוויית המשתמש בפועל ויעד ברור שאפשר לשאוף אליו. כתוצאה מכך, ערך ה-CLS ב-75% העליונים השתפר מ-0.25 ל-0.1, והאחוז של הבקשות שעברו את הבדיקה עלה מ-57% ל-72%.
250%
שיפור של אחוזון 75 ב-CLS
15%
יותר משתמשים עם ניקוד CLS גבוה
איפה התחלנו
בעזרת לוחות הבקרה של CrUX הצלחנו לקבוע שהדפים שלנו זזו יותר ממה שרצינו.
המטרה שלנו הייתה שחוויית השימוש של לפחות 75% מהקוראים תהיה "טובה", ולכן התחלנו לזהות את הגורמים לחוסר היציבות של הפריסה.
איך מדדו את שינויי הפריסה
השתמשנו בשילוב של Chrome DevTools ו-WebPageTest כדי לזהות מה גורם לשינוי הפריסה. בכלי הפיתוח, השתמשנו בקטע Experience בכרטיסייה Performance כדי להדגיש מקרים ספציפיים של שינוי הפריסה, ולהסביר איך הם השפיעו על הציון הכולל.
ב-WebPageTest, כשמפעילים את האפשרות 'הדגשת שינויים בפריסה', המערכת מדגישה את המיקום שבו מתרחש השינוי בפריסה בתצוגת ציר הזמן.
אחרי שבדקנו את כל השינויים בתבניות הנצפות ביותר שלנו, הגדרנו רשימה של רעיונות לשיפור.
הפחתת שינויי הפריסה
התמקדנו בארבעה תחומים שבהם הצלחנו לצמצם את השינויים בפריסה: - מודעות - תמונות - כותרות - הטמעות
מודעות
המודעות נטענות אחרי הצביעה הראשונית באמצעות JavaScript. לחלק מהקונטיינרים שהם העלו לא היה גובה שמובטח להם.
אנחנו לא יודעים מה הגובה המדויק, אבל אנחנו יכולים להקצות מקום על סמך גודל המודעה הנפוץ ביותר שנטען במשבצת.
במקרים מסוימים, הערך שצוין לגובה הממוצע של המודעה היה שגוי. בקוראי טאבלט, המשבצת הייתה מתכווצת.
בדקנו שוב את החריץ והתאמנו את הגובה שלו לגודל הנפוץ ביותר.
תמונות
הרבה מהתמונות באתר נטענות באיטרציה, והמקום שלהן שמור.
עם זאת, לתמונות שמוצגות בתוך הטקסט בחלק העליון של המאמרים לא הוקצה מקום בקונטיינר, ולא היו להן מאפייני רוחב וגובה שמשויכים לתגים. כתוצאה מכך, הפריסה השתנתה בזמן הטעינה של התמונות.
הוספת מאפייני הרוחב והגובה לתמונות פשוט מונעת את האפשרות שהפריסה תשתנה.
כותרת
הכותרת הייתה מתחת לתוכן בתגי העיצוב, והוצבה בחלק העליון באמצעות CSS. הרעיון המקורי היה לתת עדיפות לטעינת התוכן לפני הניווט, אבל זה גרם לדף לזוז לרגע.
העברת הכותרת לחלק העליון של הרכיב אפשרה לדף להירטן בלי המעבר הזה.
הטמעות
לחלק מהקובצי ה-embed הנפוצים יש יחס גובה-רוחב מוגדר. לדוגמה, סרטונים ב-YouTube. בזמן שהנגן נטען, אנחנו שולפים את התמונה הממוזערת מ-YouTube ומשתמשים בה כתמונה זמנית בזמן שהסרטון נטען.
מדידת ההשפעה
הצלחנו למדוד את ההשפעה ברמת התכונה בקלות יחסית באמצעות הכלים שצוינו בתחילת המאמר. עם זאת, רצינו למדוד את CLS גם ברמת התבנית וגם ברמת האתר. באופן סינתטי, השתמשנו ב-SpeedCurve כדי לאמת שינויים גם בסביבת טרום-ייצור וגם בסביבת הייצור.
לאחר שהקוד יגיע לסביבת הייצור, נוכל לאמת את התוצאות בנתוני ה-RUM שלנו (שסופקו על ידי mPulse).
בדיקת נתוני RUM מאפשרת לנו לדעת ברמה גבוהה של ביטחון שהשינויים שאנחנו מבצעים משפיעים באופן חיובי על הקוראים שלנו.
המספרים הסופיים שבדקנו הם של נתוני RUM ש-Google אוספת. זה רלוונטי במיוחד עכשיו, כי בקרוב יהיה להם השפעה על דירוג הדפים. קודם כול, השתמשנו בדוח חוויית המשתמש ב-Chrome, גם בנתונים החודשיים ברמת המקור שזמינים דרך מרכז הבקרה של CrUX, וגם על ידי שליחת שאילתה ל-BigQuery כדי לאחזר נתונים היסטוריים של p75. כך הצלחנו לראות בקלות שכל התנועה שנמדדת על ידי CrUX, השתפרה ב-250% במדד CLS ב-75% העליונים, מ-0.25 ל-0.1, והיקף הבקשות שעברו את הבדיקה גדל מ-57% ל-72%.
בנוסף, הצלחנו להשתמש ב-API של דוח חוויית המשתמש ב-Chrome וליצור כמה מרכזי בקרה פנימיים שמחולקים לתבניות.
הימנעות מנסיגות במדד CLS
הימנעות מנסיגה בביצועים היא היבט חשוב בשיפור הביצועים. הגדרנו כמה תקציבי ביצועים בסיסיים למדדי המפתח שלנו, וכללנו בהם את מדד CLS.
אם הבדיקה חורגת מהתקציב, תישלח הודעה לערוץ Slack כדי שנוכל לבדוק את הסיבה. הגדרנו גם דוחות שבועיים, כך שגם אם התקציב של התבניות לא ייגמר, נהיה מודעים לשינויים שהשפיעו לרעה על התקציב.
אנחנו גם מתכננים להרחיב את התקציבים שלנו כך שיכללו שימוש בנתוני RUM וגם בנתונים סינתטיים, באמצעות mPulse כדי להגדיר גם התראות סטטיות וגם זיהוי חריגות, כדי שנוכל לדעת על שינויים יוצאי דופן.
חשוב לנו לפתח תכונות חדשות תוך התמקדות ב-CLS. הרבה מהשינויים שציינתי הם שינויים שנאלצנו לתקן אחרי שהם פורסמו לקוראים שלנו. מעכשיו והלאה, יציבות הפריסה תהיה שיקול בתכנון הפתרונות של כל תכונה חדשה, כדי שנוכל למנוע שינויים בלתי צפויים בפריסה כבר מההתחלה.
סיכום
השיפורים שביצענו עד עכשיו היו קלים יחסית להטמעה והשפיעו באופן משמעותי. הרבה מהשינויים שתיארתי במאמר הזה בוצעו תוך זמן קצר והוחלו על כל התבניות הנפוצות ביותר, כך שהם השפיעו באופן חיובי על רבים מהקוראים שלנו.
עדיין יש אזורים באתר שאנחנו צריכים לשפר. אנחנו בוחנים דרכים שבהן נוכל לבצע יותר מהלוגיקה בצד הלקוח בצד השרת, כדי לשפר עוד יותר את CLS. נמשיך לעקוב אחרי המדדים שלנו ולנטר אותם כדי לשפר אותם באופן קבוע ולספק לקוראים שלנו את חוויית המשתמש הטובה ביותר.