ניתוח מקרה של שינויים ש-GoDaddy הטמיעה כדי לשפר את ביצועי האתרים של מיליוני אתרים, וכך לעזור להם לקבל ציונים טובים ב-PageSpeed Insights וב-Core Web Vitals.
GoDaddy היא פלטפורמת השירותים הגדולה ביותר בעולם ליזמים ברחבי העולם. המשימה שלנו היא להעצים את הקהילה הגלובלית שלנו של יותר מ-20 מיליון לקוחות – ויזמים בכל מקום – על ידי מתן כל העזרה והכלים הנחוצים להם כדי לצמוח באינטרנט.
בשנת 2019, GoDaddy השיקה את Websites + Marketing במסגרת המחויבות שלה לספק כלים ושירותים שקל להשתמש בהם ועוזר לבעלי עסקים להשיג את היעדים שלהם. ב-Websites + Marketing משולב בניית אתרים עם כלים לשיווק ולמסחר אלקטרוני, בשילוב עם הדרכה ברמה הגבוהה ביותר, כדי לעזור ללקוחות להצליח בפרויקטים החדשים שלהם.
מאז ההשקה של 'אתרים + שיווק', הביצועים היו חלק חשוב במוצר, ואנחנו עוקבים אחריהם ומשקיעים בהם מאמצים רבים. במאמר הזה נסקור את התהליך של GoDaddy, שבו החברה עברה משימוש בבדיקות ביצועים במעבדה לשימוש בנתונים מהעולם האמיתי באמצעות מדדי הליבה לבדיקת חוויית המשתמש (Core Web Vitals), ואת סדרת השיפורים שבוצעו במוצר כדי להשיג שיעור העברה גבוה מאוד באתרים של הלקוחות שלנו.
מעקב אחר הביצועים באמצעות Lighthouse
הסתמכנו על נתוני Lighthouse למעקב אחר ביצועים. בכל פעם שאתר יפורסם בפלטפורמה, נמדוד את הביצועים שלו באמצעות הכלי הפנימי שלנו שנקרא Lighthouse4u, שמספק את Google Lighthouse כשירות https://github.com/godaddy/lighthouse4u. כך קיבלנו אינדיקציה טובה לגבי הביצועים הכלליים של האתרים בהגדרה מעבדתית.
מאחר שמיליארדי האתרים שאנחנו מארחים בפלטפורמה שלנו כוללים מגוון רחב של תכונות ותוכן, היה חשוב לשלב בין נתוני הביצועים לבין מטא-נתונים לגבי כל אתר שנבדק (כמו התבנית שבה נעשה שימוש, סוג הווידג'טים שעבר רינדור וכו'). כך הצלחנו להסיק מסקנות לגבי תכונות האתר שהביצועים שלהן נמוכים יותר, וגם לקבל תובנות לגבי המקומות שבהם כדאי לחפש שיפורים.
לדוגמה, בעזרת הנתונים האלה זיהינו של'חלון קופץ מודאלי' יש השפעה שלילית על מהירות הדף. הביצועים של אתרים עם התכונה היו נמוכים ב-12 נקודות בהשוואה לאתרים בלי התכונה. אחרי ביצוע עדכונים בקוד כדי לדחות את טעינת ה-JavaScript, הצלחנו לשפר את הציון שלנו ב-Lighthouse ב-2 נקודות. הצלחנו ליישם את התובנות האלה בתכונות אחרות, כמו 'באנר קובצי ה-cookie' שמוצג זמן קצר אחרי טעינת הדף.
בנוסף לבדיקה של אתרים בעייתיים על סמך תכונות, ביצענו ניתוח של חבילת ה-JavaScript שלנו וגילינו שחלק גדול מהגודל שלה נובע מהתלות חיצוניות (immutable.js ו-draft.js). כדי לצמצם את גודל החבילה, שינינו את המבנה של הצרכנים כך שיטענו בזמן אמת רק את יחסי התלות הנדרשים. התוצאה הייתה ירידה של יותר מ-50% בגודל החבילה הנפוצה של JavaScript, מיותר מ-200KB ל-90KB בערך (אחרי אופטימיזציה). גודל החבילה הקטן יותר אפשר לדפדפן לטעון נכסים חיצוניים ולהריץ סקריפטים קריטיים בשלב מוקדם יותר במחזור החיים הראשוני של טעינת האתר, וכתוצאה מכך חל שיפור בLargest Contentful Paint (LCP) ובFirst Input Delay (FID).
הודות למאמצים המתמשכים שלנו, הציון הממוצע של אתרים של לקוחות ב-Lighthouse עלה מ-40 נקודות בערך בנובמבר 2020 ליותר מ-70 נקודות במאי 2021. עם זאת, לא כל הניסיונות שלנו צלחו, ולפעמים הופתענו כשהתוצאות לא תמיד היו עקביות בין מה שנבדק בסביבות בדיקה מקומיות לבין התוצאות שקיבלנו בשטח. תוצאות הבדיקה היו מועילות מאוד, אבל הגיע הזמן להתמקד בחוויות של משתמשים אמיתיים שנצפו בשטח.
מעקב אחר נתוני משתמשים אמיתיים באמצעות מדדי הליבה לבדיקת חוויית המשתמש (Core Web Vitals)
אחרי הוספת הספרייה web-vitals לאתרים של הלקוחות שלנו, הצלחנו למדוד נתונים במכשירים אמיתיים של מבקרים אמיתיים, שבהם החומרה, מהירות הרשת והאינטראקציה של המשתמשים (כמו גלילה או לחיצה) לא יציבים כמו בסביבת מעבדה באמצעות Lighthouse. זה היה צעד גדול בכיוון הנכון, כי עכשיו היו לנו נתונים שמייצגים את חוויית המבקרים באתר.
התמקדות בצוואר הבקבוק שלנו: מדד היציבות החזותית (CLS)
ניתוח הנתונים החדשים נתן לנו נקודת מבט חדשה לגבי הפעולות שצריך לבצע כדי לשפר את מהירות האתר. בעקבות העבודה שעשינו כדי לשפר את הציון ב-Lighthouse, ה-LCP ב-75% העליונים היה 860 אלפיות השנייה, וה-FID באותו סף היה מתחת ל-10 אלפיות השנייה. לכן, שיעור הצלחה גבוה של המדדים האלה נרשם באתרים של הלקוחות שלנו: 78% ו-98%, בהתאמה. עם זאת, המספרים של Cumulative Layout Shift (CLS) נראים שונים למדי ממה שהורגלנו לקבל ב-Lighthouse. ערך ה-CLS שלנו ב-75% העליונים היה 0.17 – מעל הסף של 0.1 ל'הצלחה' – ולכן שיעור ההצלחה שלנו היה רק 47% בכל האתרים שלנו.
המדד הזה גרם לירידה בשיעור הצלחה הכולל ל-40%, ולכן החלטנו להציב יעד שאפתני להגדלת המספר הזה ליותר מ-60% עד סוף אוגוסט 2021. כדי לעשות זאת, נצטרך להתמקד ב-CLS.
בעולם האמיתי, משתמשים יוצרים אינטראקציה עם הדף ומגללים את התוכן שמופיע מעל לחלק העליון והקבוע, וזה מה שמדדי הליבה לבדיקת חוויית המשתמש באתר מתעדים בצורה טובה יותר. בגלל השונות באופן שבו המשתמשים יוצרים אינטראקציה עם האתר בזמן הטעינה הראשונית שלו, המדד CLS שונה מהנתונים שנאספו במעבדה ובשדה.
הדרך לעבור את כל מדדי הליבה לבדיקת חוויית המשתמש באתר
כדי לשפר את הביצועים צריך לנסות ולטעות, ולא תמיד כל ניסיון עובד כמצופה. עם זאת, ריכזנו כאן כמה שיפורים שעזרו לנו להשיג את היעדים שלנו.
שמירת מקום לטעינה של תמונות שיפרה באופן משמעותי את ציון ה-CLS שלנו, כי היא מונעת את הזזת התוכן שמתחת לתמונות. הבעיה הזו טופלה באמצעות מאפיין ה-CSS aspect-ratio בדפדפנים שתומכים בו. במודעות שלא כוללות תמונה, טעננו תמונה זמנית שקופה ששמורה במטמון ושהגודל שלה הוא רק כמה בייטים, כך שהטעינה מתבצעת כמעט באופן מיידי.
התנהגות התמונה הגנרית הזו אפשרה לנו לחשב מראש את גובה התמונה הסופי במהלך העיבוד בצד השרת, על סמך רוחב אזור התצוגה ויחס הגובה-רוחב של התמונה. התוצאה הייתה סימון HTML עם שטח אנכי ששמור בצורה מתאימה לתמונה הסופית. השיפור היה ניכר במיוחד במכשירים ניידים, כי התמונות עברות רינדור לכל רוחב אזור התצוגה בנייד.
לרכיבים מסוימים באתרים של הלקוחות שלנו יש תוכן דינמי (לדוגמה, רשימה של ביקורות של לקוחות חיצוניים), ולא ניתן היה להמיר אותם ל-CSS טהור כדי לנצל את יתרונות הביצועים של עיבוד בצד השרת. קשה לשפר את השינויים בפריסה באזורים האלה כי התוכן (ולכן הגובה) משתנה. במקרים כאלה, עטפנו את הרכיב בקונטיינר עם min-height מוגדר מראש, על סמך התצפית לגבי הגובה הממוצע של כל אחד מהרכיבים הספציפיים. ה-min-height מוסר אחרי שהעיבוד של הרכיב הדינמי הפנימי מסתיים. הפתרון הזה לא מושלם, אבל הוא אפשר לנו לצמצם את השינויים בפריסה בצורה משמעותית.
בזמן שהתמקדות בשיפורי CLS, המשכנו לעבוד על LCP. באתרים רבים, תמונות הן הגורם העיקרי שמשפיע על זמן הטעינה של התוכן הוויזואלי, ולכן היה ברור לנו שזהו תחום שצריך לשפר. ביצענו שיפורים בחיוב תמונות באיטרציה באמצעות IntersectionObserver, אבל הבנו שגדלי התמונות לא הוגדרו בצורה האופטימלית ביותר לכל נקודת עצירה (נייד, טאבלט, מחשב, מחשב גדול). לכן עדכנו את הקוד ליצירת תמונות כדי לקבוע את הגודל המקסימלי של התמונות ולשנות את הגודל שלהן לפי נקודת העצירה, ולאחר מכן לשנות שוב את הרזולוציה על סמך צפיפות הפיקסלים. לדוגמה, הגודל של תמונה גדולה מסוימת הופחת מ-192KB ל-102KB.
כדי להציג במהירות אתרים במכשירים עם חיבורי רשת חלשים, הוספנו קוד שמקטין באופן דינמי את איכות התמונות בהתאם למהירות החיבור. אפשר לעשות זאת באמצעות הנכס downlink שמוחזר על ידי navigator.connection. אנחנו מחילים פרמטרים של שאילתות שמבוססים על כתובות URL כדי להפחית את איכות התמונות דרך Asset API שלנו, על סמך תנאי הרשת האלה.
חלק מהקטעים באתרים של הלקוחות שלנו נטענים באופן דינמי. מכיוון שאנחנו יודעים אילו קטעים ייראו באתר מסוים אחרי הפרסום שלו, השתמשנו ברמז המשאב rel=preconnect כדי לאתחל מראש את החיבור ואת לחיצות היד הנדרשות. אנחנו גם משתמשים בטיפים לגבי משאבים כדי לטעון גופנים ומשאבים חשובים אחרים במהירות.
כשלקוחות יוצרים אתרים, הם מוסיפים קטעים שונים שעשויים לכלול סקריפטים מוטמעים כדי לאפשר פונקציות שונות. הצבת הסקריפטים האלה בתוך הדף ב-HTML לא תמיד משפרת את הביצועים. החלטנו להעביר את הסקריפטים האלה לגורם חיצוני כדי לאפשר לדפדפן לטעון ולנתח את תוכן הסקריפט באופן אסינכררוני. אפשר גם לשתף סקריפטים חדשים שהועברו לצד החיצוני בין דפים. כך הצלחנו לשפר את הביצועים באמצעות שמירת נתונים במטמון בדפדפן וב-CDN. שמנו סקריפטים קריטיים בתוך שורת הקוד כדי שהדפדפן יוכל לנתח ולבצע אותם מהר יותר.
תוצאות
ההתמקדות שלנו במדד CLS השתלמה: שיעור העמידה בדרישות של מדדי הליבה לבדיקת חוויית המשתמש באתר עלה מ-40% ל-70%, כלומר שיפור של 75%!
כשמשתמשים חוזרים לפלטפורמה שלנו כדי לבצע עדכונים ולפרסם מחדש את האתרים שלהם, הם מקבלים את שיפורי הביצועים העדכניים ביותר. כתוצאה מכך, מספר האתרים שעומדים בדרישות של Core Web Vitals גדל בהתמדה, כפי שמוצג בתרשים הבא:
מסקנות
איתור תחומים שבהם אפשר לשפר את הביצועים ומעקב מוצלח אחר ההתקדמות תלויים במידה רבה בכלים שבהם משתמשים למדידת הביצועים. Lighthouse היה שימושי למדידת הביצועים של החלק העליון של הדף 'במצב מעבדה', אבל הוא לא תיעד בצורה מדויקת בעיות בביצועים שנגרמו רק כתוצאה מאינטראקציות של משתמשים (כמו גלילה בדף).
מעקב אחר מדדי הליבה לבדיקת חוויית המשתמש באתר בעולם האמיתי באמצעות מטא-נתונים אפשר לנו להציג בגרפים את ההשפעה של השיפורים שלנו, לטרגט אותם ולמדוד אותם. התהליך לשיפור הציונים של מדדי הליבה לבדיקת חוויית המשתמש באתר אפשר לצוות לזהות ולהחלף דפוסים עם ביצועים נמוכים שנמצאו בקוד הבסיסי שלנו. לפעמים שינויים מבטיחים לא השפיעו כמעט כמו שציפינו, ולפעמים קרה ההיפך. העולם לא מושלם, לכן צריך להמשיך לנסות.