מספר חודשים של עבודה לשיפור מדדי הליבה לבדיקת חוויית המשתמש בדף הבית של Mail.ru, הובילה לעלייה של 60% באחוזון ה-75 של Cumulative Layout Shift (CLS), להאריך את משך הסשן ב-2.7% הממוצע ולשפר את שיעורי ההמרות של קטעי ליבה בשיעור של יותר מ-10%.
איפה התחלנו
Mail.ru הוא אחד משירותי האימייל המובילים באינטרנט דוברי רוסית, והוא נמצא ב-5 האתרים המובילים ברוסיה מבחינת תנועה. Mail.ru הוא משאב חשוב לאנשים רבים. האתר מקבל כמה מאות מיליון ביקורים בחודש, והוא פורטל שממנו אנשים יכולים לגשת לאימייל, לחדשות, למדיה חברתית, לחיפושי ביצועים באינטרנט ועוד.
המטרה של Mail.ru הייתה לספק למבקרים באתר חוויית משתמש איכותית, ולכן התחלנו לשפר את מדדי הליבה לבדיקת חוויית המשתמש באתר. לפני שנדון באסטרטגיית האופטימיזציה שלנו, אנו רוצים לציין תחילה כמה פרטים טכניים לגבי דף הבית של Mail.ru.
למרות שהפרויקט פותח כבר זמן רב באמצעות מנוע התבניות הפנימי שלנו, Fest, התחלנו לעבור ל-Svelte 3 בשנת 2019.
Svelte מטמיע את התגובה באופן שלא משתמש ב-Virtual DOM, וכך הוא צורך פחות משאבים. הגישה של Svelte מסירה פונקציות שלא בשימוש מחבילות ייצור, מאחר שהקוד שמטמיע אותן לא נוצר על ידי המהדר אם לא משתמשים בפונקציות. קוד שלא נמצא בשימוש מוסר במהלך ההידור, וכתוצאה מכך נוצרות חבילות קטנות יותר. ההגדרה הזו יכולה לקצר את זמן החסימה הכולל (TBT) במהלך ההפעלה של הדף.
מעקב אחרי מדדי ביצועים
לפני שמבצעים אופטימיזציה של מדדי הליבה לבדיקת חוויית המשתמש באתר, מומלץ להעריך את הביצועים בשטח. לפני שבדקנו את מדדי הליבה לבדיקת חוויית המשתמש באתר, בדקנו מדדים אחרים כמו הצגת תוכן ראשוני (FCP) במרכז הבקרה הפנימי לבדיקת ביצועים.
הסקריפט של איסוף המדדים השתנה כדי לאסוף מדדי ליבה לבדיקת חוויית המשתמש באתר ולהעביר אותם למרכז הבקרה של הביצועים לצורך המחשה חזותית. בהתאם להמלצות של Google, הסקריפט שלנו משתמש ב-PerformanceObserver API כדי להשיג מדדים, שהם חלק מהפלטפורמה האוניברסלית "Platform" ב-Mail.ru.
במרכז הבקרה הוצגו למשתמשים המדדים הבאים (הערכים הממוצעים לשבוע 15-21 במרץ 2021):
| שם קבוצת המדדים | דוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) | מדדי Web Vitals אחרים | |||||
|---|---|---|---|---|---|---|---|
| שם המדד | LCP | FID | CLS | FCP | טרם נקבע | מדריך אינטראקטיבי | |
| נתח המשתמשים בהתאם לערכי הסף של דוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) | good, טוב | 52% | 92% | 33% | 35% | 42% | 43% |
| שיפור צרכים | 19% | 5% | 23% | 38% | 16% | 25% | |
| חלשה | 29% | 3% | 44% | 27% | 42% | 32% | |
שיפור מדדי הליבה לבדיקת חוויית המשתמש באתר
יש הרבה הדרכות לשיפור מדדי הליבה לבדיקת חוויית המשתמש באתר, אבל לכל פרויקט יש אתגרים ייחודיים. בדף הבית של Mail.ru זוהו ההזדמנויות הבאות:
- הטמעת placeholders עבור מודעות באנר כדי לצמצם את CLS.
- שימוש בעיבוד בצד השרת (SSR) לצמצום המהירות שבה נטען רכיב התוכן הכי גדול (LCP).
- פיצול קוד להפחתת LCP ו-השהיה לאחר קלט ראשון (FID).
שלדים לשיפור CLS
מדד CLS היה אחד ממדדי השדות שהביצועים שלהם הם הגרועים ביותר בדף הבית של Mail.ru. לאחר מכן, הפרופיילינג של הדף הזה בחלונית Performance (ביצועים) בכלי הפיתוח של Chrome הראה שהמודעות היו המקור לבעיה. כדי לשפר את יציבות הפריסה, הצוות שלנו החליט להשתמש ב-placeholders כדי לשריין מקום למודעות לפני שהן ייטענו.
כשמיישמים placeholders, השלב הראשון הוא לקבוע את מאפייני התוכן שיחליפו אותם. למרבה המזל, לגרסה למחשב של דף הבית של Mail.ru יש גדלים מתועדים היטב של מודעות. אחרי שדיברנו עם צוות העיצוב, שלדים של ממשק המשתמש עם אנימציה של SVG שימשו כ-placeholders כדי שהם מפחיתים את זמן הטעינה של התוכן.
חזרתו של SSR
כדי להקל על המעבר מ-Fest ל-Svelte, שכתבנו בהדרגה את הפרויקט הקיים במקום להתחיל מחדש. עד מרץ 2021, העברנו את רוב ממשק הקצה ל-Svelte, ובסופו של דבר הוספנו את SSR לאפליקציה בסביבת הייצור שלנו אחרי מיון ותיקון של בעיות בביצועים בקצה העורפי.
לאחר יישום SSR, הצוות גילה את הסיבה לרגרסיית CLS שלא הייתה מובנת בהתחלה: קטע החדשות לא נוסף ברגע הרינדור של התוכן הראשון בדף. חל עיכוב בין הציור הראשוני של סימון הדף שסופק על ידי השרת לבין ההוספה של קטע חדשות אצל הלקוח. ההתנהגות הזו הובילה לשינוי בשלד של המודעות, שהחמיר את ה-CLS.
כלי הפיתוח של Chrome מציגים אירועי Layout Shift, אבל לא הצלחנו למצוא את הסיבה לכך בהתחלה. למרות ש-SSR עצמה לא הייתה הבעיה, היא עזרה במציאת הפתרון בהמשך. תיקון הקוד שאחראי לעיכוב בציור שיפר את יציבות הפריסה של רכיב החדשות.
השפעה נוספת של SSR על CLS היא התנועה של רכיבים לפני ואחרי מאזן הנוזלים, שעשויה להוביל לשינויים נוספים בפריסה. נתקלנו בבעיה הזו במיוחד בגרסה לנייד, והיה צורך להקדיש תשומת לב מיוחדת לתגי העיצוב של רכיבי המים. פתרון טוב לבעיה הזו היה העברת כמה שיותר לוגיקה של תצוגה מ-JavaScript ל-CSS, במידת האפשר.
פיצול קוד ו-polyfills שלא בשימוש
כדי לשפר את המהירות הנתפסת של טעינת הדף, נדרשת הפחתה של ערכי LCP ו-FID. אחת מהדרכים לעשות זאת היא באמצעות פיצול קוד. בנוסף לדף הבית עצמו של Mail.ru, הצוות שלנו מפתח ווידג'ט לניווט בפורטל. נכון לעכשיו, הוא מוטמע ברבים מהפרויקטים של החברה שלנו.
מסיבות היסטוריות, הווידג'ט מוכנס ממש בתחילת הדף כסקריפט שנטען באופן סינכרוני. נתח הפוליפים בסקריפט הזה גדל עם הזמן. כדי להגביל את ההשפעות השליליות על הביצועים של טעינת פולימלאים כאלה, הטמענו פיצול קוד גם לדפדפנים מודרניים וגם לדפדפנים מדור קודם.
החלטנו שלא להשתמש בדפוס module/nomodule לטעינת חבילות JavaScript לדפדפנים מודרניים או מדור קודם, כי מאפיין type="module" של האלמנט <script> לא טירגטת לדפדפנים שהיו חדישים מספיק את הצרכים שלנו. כדי לפתור את הבעיה, Mail.ru משתמש בכלי פנימי לזיהוי גרסאות מודרניות של דפדפנים בצד העורפי, ויכול להתאים את עצמו לדפדפנים האלה בהתאם.
ברגע שאפשר היה לזהות דפדפנים בקצה העורפי, הטמענו פיצול קוד לדפדפנים מודרניים ולדפדפנים מדור קודם. התוצאה הייתה ירידה של 43.3% בגודל של ווידג'ט ה-JavaScript שנטען באופן סינכרוני עבור דפדפנים מודרניים. השיטה הזו יושמה גם במספר סקריפטים אחרים של פורטלים.
בנוסף להקטנת גודל החבילה ולהשפעה החיובית על מדדי הליבה לבדיקת חוויית המשתמש באתר, פיצול הקוד משפר גם את חוויית המפתח. רק 3.5% מהמשתמשים שלנו משתמשים בדפדפנים מדור קודם, והנתח הזה נמצא במגמת ירידה. לכן, הטמעת הקוד אפשרה למפתחים שלנו להשתמש בממשקי ה-API העדכניים ביותר לדפדפנים, מבלי להשיק לכל המשתמשים את ה-ריבוי של מסננים רב-פעמיים שנדרש לדפדפנים מהדור הקודם.
תוצאות
אחרי מאמץ האופטימיזציה, שמנו לב לערכים הממוצעים של השבוע 24-30 במאי 2021 בנתוני השדות שלנו:
| שם קבוצת המדדים | דוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) | מדדי Web Vitals אחרים | |||||
|---|---|---|---|---|---|---|---|
| שם המדד | LCP | FID | CLS | FCP | טרם נקבע | מדריך אינטראקטיבי | |
| נתח המשתמשים בהתאם לערכי הסף של דוח המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) | good, טוב | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| שיפור צרכים | 18% | 4% | 3% | 34% | 17% | 24% | |
| חלשה | 24% | 3% | 4% | 23% | 34% | 25% | |
בתרשימים שבהמשך מוצגים שינויים בערכי מדדי הביצועים של דפי אינטרנט לפי ה'פלטפורמה'. שימו לב לשני התאריכים החשובים שמוצגים בתרשימים:
- 23 במרץ 2021: הגרסה של איטרציה עם קטעי הדף האחרונים הועברה ל-Svelte;
- 19 באפריל 2021: השקת האיטרציה עם SSR שהוחזרו והפריסה שלו שונתה כדי לתקן רגרסיות של CLS.
הירידה בערכים מ-1 במאי עד 10 במאי קשורה לחגים של מאי ברוסיה.
התוצאות שהתקבלו באמצעות ה "פלטפורמה" תואמות לגידול בערכי המדדים בדוח חוויית המשתמש של Chrome (CrUX).
בהשוואה בין ערכי משך הסשן הממוצע של המשתמשים בשבוע שלפני השקת השיפורים הראשוניים ושבוע לאחר ההשקה אפשר לראות עלייה של 2.7%. בנוסף, יש עלייה משמעותית כוללת בהמרות ברוב קטעי הדף. באופן ספציפי, מספר ההמרות לאפליקציית האימייל Mail.ru עלה ב-11.6%, שיעור ההמרות במדור החדשות גדל ב-13.5%.
181%
עלייה בנתח של סף CLS טוב
2.7%
משך סשן ממוצע גבוה יותר
13.5%
עלייה בשיעור ההמרות מקטעי החדשות
התוצאה הכי לא צפויה שקיבלנו הייתה עלייה של 17.4% בשיעור הקליקים (CTR) של הבאנר השיווקי (זמן הרינדור שלו הצטמצם באופן משמעותי על ידי הוספת תגי SSR ותגי טעינה מראש).
לאחר ניתוח שאר הקטעים בדף, הבחנו בשיפור משמעותי בביצועים ברובם. גם במדורים כמו 'מזג האוויר' ו'נגיף הקורונה' (COVID-19), שאינם קריטיים בדף שלנו, רואים עלייה של 9.6% ב-9.5%, בהתאמה.
סיכום
השיפור בביצועים עלול להיות מאתגר מכיוון שהעבודה הכרוכה בו עשויה להימשך זמן רב. יש לעקוב באופן קבוע אחר השינויים במדדים לאורך זמן ולוודא שכל התכונות החדשות של המוצר לא גורמות לרגרסיות במדדי הליבה לבדיקת חוויית המשתמש באתר. כדי להשיג זאת, אנחנו עוקבים אחר השינויים במדדי הליבה לבדיקת חוויית המשתמש באתר בתקציב הביצועים שלנו.
והכי חשוב, הדגשנו את החשיבות של מדדי הליבה לבדיקת חוויית המשתמש באתר לכל החברים בצוות המוצר, החל מהמנהלים והמעצבים ועד לבודקים ולבקרת האיכות. כל אחד מחברי הצוות צריך להיות מודע למדדי הביצועים ולקבל את היכולת לשפר אותם. אנחנו גם משלבים יעדים של אופטימיזציה של ביצועים בתהליכים העסקיים שלנו על בסיס קבוע. כדי לספק חוויית משתמש באיכות גבוהה יש לעשות רק מאמץ משותף של כל חברי הצוות.