מקרה לדוגמה של שינויים שהוטמעו ב-GoDaddy כדי לשפר את ביצועי האתרים של מיליוני אתרים, וכך השיגו ציונים טובים ב-PageSpeed Insights ובמדדי הליבה לבדיקת חוויית המשתמש באתר.
GoDaddy היא פלטפורמת השירותים הגדולה ביותר בעולם ליזמים. המטרה שלנו היא להעצים את הקהילה העולמית שלנו, שכוללת יותר מ-20 מיליון לקוחות, ויזמים בכל מקום, באמצעות כל העזרה והכלים הדרושים להם כדי לצמוח באינטרנט.
ב-2019 השקנו את GoDaddy + Marketing, מתוך מחויבות לספק כלים ושירותים קלים לשימוש שיעזרו לבעלי עסקים להשיג את היעדים שלהם. בחברת Sites + Marketing משלבים בבניית אתרים כלים שיווקיים וכלים למסחר אלקטרוני, ומשלבים ביניהם את ההנחיות המובילות שיעזרו ללקוחות להצליח ביוזמות החדשות שלהם.
מאז ההשקה של Website + Marketing (אתרים ושיווק), הביצועים היו חלק חשוב מהמוצר וכחלק מתהליך המעקב והטיפול בו עבדנו באופן פעיל. במאמר הזה נציג את התהליך של GoDaddy, משלב השימוש בבדיקות הביצועים במעבדה ועד לשימוש בנתונים מהעולם האמיתי במדדי הליבה לבדיקת חוויית המשתמש באתר, ונעבור על סדרת השיפורים שבוצעו במוצר כדי להשיג שיעור גבוה מאוד של הרשאות גישה לאתרים של הלקוחות.
מעקב אחר ביצועים באמצעות Lighthouse
הסתמכנו על נתוני Lighthouse לצורך מעקב אחר הביצועים. בכל פעם שאתר מפורסם בפלטפורמה, אנחנו מודדים את הביצועים שלו באמצעות הכלי הפנימי שלנו שנקרא "Lighthouse4u", שמספק את Google Lighthouse כשירות https://github.com/godaddy/lighthouse4u. הנתון הזה סיפק לנו אינדיקציה טובה לגבי הביצועים של אתרים באופן כללי בהגדרת שיעור Lab.
מכיוון שמיליוני האתרים שאנחנו מארחים בפלטפורמה שלנו כוללים מגוון רחב של תכונות ותוכן, היה חשוב לשלב את נתוני הביצועים עם מטא-נתונים לגבי כל אתר שנבדק (למשל באמצעות התבנית שבה נעשה שימוש, סוג הווידג'טים שמעובדים וכו'). כך הצלחנו להסיק מסקנות לגבי התכונות באתר שהניבו ביצועים נמוכים, וגם להבין איפה כדאי לחפש שיפורים.
לדוגמה, זה עזר לנו לזהות שלחלון הקופץ הקופץ הייתה השפעה שלילית על מהירות הדף. הביצועים של אתרים עם התכונה הזו היו נמוכים ב-12 נקודות מאשר בלעדיהם. אחרי שביצענו עדכונים בקוד כדי לדחות את הטעינה של JavaScript, שיפרנו את הציון ב-Lighthouse ב-2 נקודות. הצלחנו ליישם את הלמידה הזו בתכונות אחרות, כמו 'באנר של קובצי cookie' שמוצג זמן קצר לאחר טעינת הדף.
בנוסף לבדיקה של אתרים בעייתיים שמבוססים על תכונות, ערכנו ניתוח של חבילת JavaScript וגילינו שחלק גדול מהגודל שלה מגיע מיחסי תלות חיצוניים (immutable.js ו- draft.js). כדי להקטין את גודל החבילות, שינינו את המבנה של הצרכנים לתלויות בעומסים איטיים לפי דרישה. כתוצאה מכך, חלה ירידה של יותר מ-50% בגודל החבילה המשותפת של JavaScript, שגדולה מ-200KB לכ-90KB (הקטנה). גודל החבילה הקטן יותר אפשר לדפדפן לטעון נכסים חיצוניים ולהפעיל סקריפטים קריטיים בשלב מוקדם יותר במחזור החיים של טעינת האתר הראשונית, וכתוצאה מכך גדלו המהירות שבה נטען רכיב התוכן הכי גדול (LCP) והשהיה לאחר קלט ראשון (FID).
הודות למאמצים המתמשכים שלנו, הציון הממוצע של אתר הלקוחות ב-Lighthouse השתנה מכ-40 נקודות בנובמבר 2020 למעל 70 נקודות במאי 2021. עם זאת, לא כל הניסיונות עזרו לנו, ולפעמים הופתענו כשהתוצאות לא תמיד היו עקביות בין מה שנבדק בסביבות בדיקה מקומיות לבין התוצאות שקיבלנו בשטח. תוצאות ה-Lab היו מועילות מאוד, אבל הגיע הזמן להתמקד בחוויות משתמש אמיתיות שנמדדו בשטח.
מעקב אחרי נתוני משתמשים אמיתיים באמצעות מדדי ליבה לבדיקת חוויית המשתמש באתר
אחרי שהוספנו את ספריית web-vitals לאתרים של הלקוחות שלנו, הצלחנו למדוד נתונים ממבקרים אמיתיים שנמדדו במכשירים בפועל, שבהם החומרה, מהירות הרשת ואינטראקציה של משתמשים (כמו גלילה או לחיצה) לא היו ברמה זהה לזו שבהגדרות במעבדה באמצעות Lighthouse. זה היה צעד גדול בכיוון הנכון, כי עכשיו יש לנו נתונים שמייצגים את החוויה של המבקרים באתר.
התמקדות בקישור החלש ביותר שלנו: Cumulative Layout Shift (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 כדי לטפל בבעיה בדפדפנים שתומכים בכך. במקרים שבהם אין אפשרות כזו, טענו תמונת placeholder שקופה שנשמרה במטמון ובגודל של כמה בייטים בלבד, ולכן הטעינה מתבצעת כמעט מיידית.
ההתנהגות הכללית הזו של התמונות אפשרה לנו לחשב מראש את גובה התמונה הסופי במהלך רינדור בצד השרת, על סמך רוחב אזור התצוגה ויחס הגובה-רוחב של התמונה. כתוצאה מכך, נוצר תגי עיצוב של HTML עם שטח אנכי ששמור כראוי לתמונה הסופית. השיפור בולט במיוחד במכשירים ניידים, כי רינדור התמונות מתבצע לכל אזור התצוגה במכשירים ניידים.
רכיבים מסוימים באתרים של הלקוחות שלנו מכילים תוכן דינמי (לדוגמה, רשימה של ביקורות חיצוניות של לקוחות) ולא ניתן להמיר אותם ל-CSS טהור כדי למנף את יתרונות הביצועים של רינדור בצד השרת. אלה אזורים שקשה לשפר את השינויים בפריסה כי התוכן (הגובה הזה) ישתנה. במקרים כאלה עטפנו את הרכיב בקונטיינר באמצעות min-height, שנקבע מראש לפי הגובה הממוצע של כל אחד מהרכיבים הספציפיים. ה-min-height מוסר בסיום העיבוד של הרכיב הדינמי הפנימי. הפתרון הזה לא מושלם, אבל מאפשר לנו לצמצם משמעותית את שינוי הפריסה.
תוך התמקדות בשיפורים ב-CLS, המשכנו לעבוד על LCP. באתרים רבים, התמונות הן המקור העיקרי ל-LCP, ועבורנו, היה זה תחום שיפור מובן מאליו. ביצענו שיפורים בתמונות עם טעינה מדורגת באמצעות IntersectionObserver, אבל הבנו שגודל התמונות לא הוגדר בצורה האופטימלית לכל נקודת עצירה (נייד, טאבלט, מחשב, מחשב, מחשב גדול). לכן עדכנו את הקוד ליצירת תמונות כך שכל התמונות יהיו מוצמדות וגודלן בכל נקודת עצירה, ואז שוב רזולוציית שינוי הגודל על סמך דחיסות הפיקסלים. כך למשל, התמונה גדולה ספציפית הוקטנה מ-192KB ל-102KB.
כדי לעבד אתרים במהירות במכשירים עם חיבורי רשת חלשים, הוספנו קוד שמאפשר להפחית באופן דינמי את איכות התמונה על סמך מהירות החיבור. ניתן לעשות זאת באמצעות המאפיין downlink שהוחזר על ידי navigator.connection. אנחנו מחילים פרמטרים של שאילתות על סמך כתובות URL כדי להפחית את איכות התמונות דרך ה-API של הנכסים הדיגיטליים שלנו על סמך תנאי הרשת האלה.
מספר קטעים באתרי הלקוחות שלנו נטענים באופן דינמי. אנחנו יודעים אילו קטעים יוצגו באתר נתון כשהוא יפורסם, לכן השתמשנו ברמז למשאב rel=preconnect כדי להתחיל את החיבור ואת לחיצות היד הנדרשות מראש. אנחנו גם משתמשים בהטיפים למשאבים כדי לטעון במהירות גופנים ומשאבים חשובים אחרים.
במהלך בניית האתרים שלהם, הלקוחות מוסיפים קטעים שונים שעשויים להכיל סקריפטים מוטבעים כדי לאפשר פונקציות שונות. הצבת הסקריפטים בדף ה-HTML לא תמיד אופטימלית לביצועים. החלטנו להפיץ את הסקריפטים האלה כדי לאפשר לדפדפן לטעון ולנתח את תוכן הסקריפטים באופן אסינכרוני. סקריפטים חדשים שהוחרגו יכולים גם להיות משותפים בין דפים. דבר זה מאפשר שיפורי ביצועים נוספים בצורת שמירה במטמון של דפדפן ו-CDN. שמרנו את הסקריפטים הקריטיים בשורה כדי שהדפדפן ינתח ויפעיל אותם מהר יותר.
תוצאות
לאחר שהמאמץ שלנו להתמקד ב-CLS השתלם, שיעור המעברים של מדדי הליבה לבדיקת חוויית המשתמש באתר עלה מ-40% לכמעט 70%: שיפור של 75%!
כשמשתמשים חוזרים לפלטפורמה שלנו כדי לערוך עדכונים ולפרסם את האתרים שלהם מחדש, הם נהנים מהשיפורים האחרונים בביצועים. כתוצאה מכך, מספר האתרים עם "עובר את מדדי הליבה לבדיקת חוויית המשתמש באתר" גדל בהתמדה, כפי שמוצג בתרשים הבא:
מסקנות
היכולת למצוא תחומים לשיפור הביצועים ולעקוב אחר ההתקדמות בהצלחה תלויה מאוד בכלים המשמשים למדידה. Lighthouse היה שימושי למדידת ביצועים בחלק העליון והקבוע ב'הגדרת שיעור Lab', אבל לא תועדו באופן מדויק בעיות בביצועים שהתרחשו רק בעקבות אינטראקציות של משתמשים (כמו גלילה בדף).
מעקב אחרי מדדי ליבה לבדיקת חוויית המשתמש באתר באמצעות מטא-נתונים אפשר לנו להציג באופן חזותי, לטרגט ולמדוד את ההשפעה של השיפורים שלנו. המסע לשיפור הציונים בדוח המדדים הבסיסיים של חוויית המשתמש אפשר לצוות לזהות ולהחליף דפוסים לא יעילים שנמצאו ב-codebase שלנו. לפעמים לשינויים מבטיחים לא הייתה כמעט השפעה הצפויה, ולפעמים ההפך קרה. לא מדובר בעולם בתולי, ולכן צריך להמשיך לנסות.