כמה חודשים של עבודה לשיפור המדדים הבסיסיים של חוויית המשתמש בדף הבית של Mail.ru הביאו לעלייה של 60% ב-75 percentile של שינוי 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 כדי לקבל מדדים, שהוא חלק מ'פלטפורמה' של ממשק הקצה האוניברסלי ב-Mail.ru.
בלוח הבקרה הוצגו המדדים הבאים לגבי משתמשים (ערכים ממוצעים לשבוע שבין 15 ל-21 במרץ 2021):
| השם של קבוצת המדדים | Core Web Vitals | מדדי Web Vitals אחרים | |||||
|---|---|---|---|---|---|---|---|
| שם המדד | LCP | FID | CLS | FCP | TBT | TTI | |
| נתח המשתמשים בהתאם לערכי הסף של מדדי הליבה לבדיקת חוויית המשתמש באתר | נהניתי | 52% | 92% | 33% | 35% | 42% | 43% |
| needs-improvement | 19% | 5% | 23% | 38% | 16% | 25% | |
| חלשה | 29% | 3% | 44% | 27% | 42% | 32% | |
שיפור מדדי הליבה לבדיקת חוויית המשתמש באתר
יש הרבה הנחיות לשיפור המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals), אבל לכל פרויקט יש אתגרים ייחודיים. בדף הבית של Mail.ru זוהו ההזדמנויות הבאות:
- הטמעת placeholders למודעות באנר כדי לצמצם את CLS.
- שימוש ברנדר בצד השרת (SSR) כדי לצמצם את הזמן שבו מוצג רכיב התוכן הכי גדול (LCP).
- פיצול קוד כדי לצמצם את LCP ואת השהיה לאחר קלט ראשוני (FID).
סקלטונים לשיפור ה-CLS
מדד CLS היה אחד ממדדי השדה עם הביצועים הגרועים ביותר בדף הבית של Mail.ru. ניתוח פרופיל של הדף הזה בחלונית ביצועים של DevTools ב-Chrome גילה שהמודעות היו מקור הבעיה. כדי לשפר את יציבות הפריסה, הצוות שלנו החליט להשתמש בסמלי placeholder כדי להקצות מקום למודעות לפני שהן נטענות.
כשמטמיעים placeholder, השלב הראשון הוא לקבוע את המאפיינים של התוכן שיחליף אותם. למרבה המזל, בגרסת דף הבית של Mail.ru למחשב יש גדלים מפורטים של מודעות. אחרי שיחה עם צוות העיצוב, השתמשנו באנימציות SVG של שלדי ממשק משתמש כערכי placeholder, כי הן מקצרות את זמן הטעינה של התוכן.
החזרת ה-SSR
כדי להקל על המעבר מ-Fest ל-Svelte, כתבנו מחדש את הפרויקט הקיים באופן מצטבר במקום להתחיל מחדש. עד מרץ 2021, העברנו את רוב חזית האתר ל-Svelte, ובסופו של דבר הוספנו את SSR לאפליקציה בסביבת הייצור אחרי שטיפלנו בבעיות בביצועים של הקצה העורפי ותיקנו אותן.
אחרי הטמעת ה-SSR, הצוות גילה את הסיבה לרגרסיה ב-CLS שלא נצפתה בהתחלה: קטע החדשות לא הוכנס בזמן העיבוד של התוכן הראשון בדף. היה עיכוב בין הצביעה הראשונית של הרכיבים של הדף שסופקו על ידי השרת לבין ההוספה של קטע החדשות בצד הלקוח. ההתנהגות הזו גרמה לתנועה של שלד המודעה, שהחמירה את מדד CLS.
בכלים למפתחים של Chrome הוצגו אירועי Layout Shift, אבל בהתחלה לא הצלחנו למצוא את הסיבה לכך. הבעיה לא הייתה ב-SSR עצמו, אבל הוא עזר לנו לגלות את הפתרון בהמשך. תיקון הקוד שאחראי לעיכוב בציור שיפר את יציבות הפריסה של רכיב החדשות.
השפעה נוספת של SSR על CLS היא תנועת הרכיבים לפני ואחרי ההידרציה, שעלולה להוביל לשינויים נוספים בפריסת הדף. נתקלנו בבעיה הזו במיוחד בגרסה לנייד, והיה צריך להקדיש תשומת לב מיוחדת לסימון הרכיבים המשופר. פתרון טוב לבעיה הזו היה להעביר כמה שיותר לוגיקה של תצוגה מ-JavaScript ל-CSS, כשהדבר אפשרי.
פיצול קוד ו-polyfills שלא בשימוש
כדי לשפר את מהירות הטעינה של הדף, נדרשה עבודה כדי להפחית את ערכי ה-LCP ו-FID. אחת מהדרכים לעשות זאת היא באמצעות חלוקת קוד. בנוסף לדף הבית של Mail.ru, הצוות שלנו מפתח ווידג'ט לניווט בפורטל. הוא מוטמע כרגע בפרויקטים רבים של החברה.
מטעמי היסטוריה, הווידג'ט מוטמע בתחילת הדף כסקריפט שנטען באופן סינכרוני. עם הזמן, החלק של הפוליפילים בסקריפט הזה גדל. כדי להגביל את ההשפעות השליליות על הביצועים של טעינת ה-polyfills האלה, הטמענו פיצול קוד גם בדפדפנים מודרניים וגם בדפדפנים מדור קודם.
החלטנו שלא להשתמש בתבנית module/nomodule לטעינה של חבילות JavaScript לדפדפנים מודרניים או לדפדפנים מדור קודם, כי המאפיין type="module" של רכיב <script> לא טירגט דפדפנים שהיו מודרניים מספיק לצרכים שלנו. כדי לטפל בבעיה הזו, ב-Mail.ru משתמשים בכלי פנימי לזיהוי גרסאות דפדפנים מודרניות בקצה העורפי, ויכולים להתאים את עצמם לדפדפנים האלה בהתאם.
אחרי שהצלחנו לזהות דפדפנים בקצה העורפי, הטמענו פיצול קוד לדפדפנים מודרניים ודפדפנים מדור קודם. התוצאה הייתה הפחתה של 43.3% בגודל הווידג'ט של JavaScript שנטען באופן סינכרוני בדפדפנים מודרניים. השיטה הזו הופעלה גם בסקריפטים אחרים של פורטלים.
בנוסף להקטנת גודל החבילה ולהשפעות החיוביות על מדדי הליבה לבדיקת חוויית המשתמש, פיצול הקוד משפר גם את חוויית המפתחים. רק 3.5% מהמשתמשים שלנו משתמשים בדפדפנים מדור קודם, והנתון הזה נמצא במגמת ירידה. לכן, הטמעת פיצול הקוד אפשרה למפתחים שלנו להשתמש בממשקי ה-API העדכניים ביותר של הדפדפנים בלי להוסיף את הקוד העודף של ה-polyfill שנחוץ לדפדפנים מדור קודם לכל המשתמשים.
תוצאות
אחרי מאמצי האופטימיזציה, ראינו את הערכים הממוצעים בשבוע של 24 עד 30 במאי 2021 בנתוני השדה שלנו:
| השם של קבוצת המדדים | Core Web Vitals | מדדי Web Vitals אחרים | |||||
|---|---|---|---|---|---|---|---|
| שם המדד | LCP | FID | CLS | FCP | TBT | TTI | |
| נתח המשתמשים בהתאם לערכי הסף של מדדי הליבה לבדיקת חוויית המשתמש באתר | נהניתי | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| needs-improvement | 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 ו-preload).
אחרי שניתחנו את שאר הקטעים בדף, שמנו לב לשיפור משמעותי בביצועים ברובם המכריע. אפילו בקטעים כמו 'מזג האוויר' ו'קורונה' – שהם לא קטעים מרכזיים בדף שלנו – ראינו עלייה של 9.6% ו-9.5% בהמרות, בהתאמה.
סיכום
שיפור הביצועים הוא אתגר, כי העבודה הכרוכה בו עשויה להימשך זמן רב. מומלץ לעקוב באופן קבוע אחרי השינויים במדדים לאורך זמן ולוודא שכל התכונות החדשות של המוצר לא גורמות לנסיגה במדדי Core Web Vitals. כדי לעשות זאת, אנחנו עוקבים אחרי השינויים במדדי Core Web Vitals בתקציב הביצועים שלנו.
הכי חשוב, הדגשנו את החשיבות של המדדים הבסיסיים של חוויית המשתמש (Core Web Vitals) לכל חברי צוות המוצר שלנו, החל מהמנהלים והמעצבים ועד למבדקים ולבקרת איכות. כל חבר צוות צריך להיות מודע למדדי הביצועים ויכול לשפר אותם. אנחנו גם משלבים יעדים של אופטימיזציה של ביצועים בתהליכים העסקיים שלנו באופן קבוע. כדי לספק חוויית משתמש באיכות גבוהה, צריך מאמץ משותף של כל חברי הצוות.