צוות האינטרנט ב-Zalando גילה ששילוב של Lighthouse CI מאפשר גישה יזומה לביצועים, עם בדיקות סטטוס אוטומטיות שיכולות להשוות בין ההתחייבות הנוכחית להסתעפות הראשית כדי למנוע נסיגה בביצועים.
Zalando היא פלטפורמת האופנה המובילה באירופה, עם יותר מ-35 מיליון לקוחות פעילים. בפוסט הזה נסביר למה התחלנו להשתמש ב-Lighthouse CI, את קלות ההטמעה ואת היתרונות לצוות שלנו.
ב-Zalando אנחנו יודעים מה הקשר בין ביצועי האתר לבין ההכנסות. בעבר, בדקנו איך הארכת משך הטעינה באופן מלאכותי בדפי קטלוג משפיעה על שיעורי העזיבה, על שיעורי ההמרה ועל ההכנסה למשתמש. התוצאות היו ברורות. שיפור של 100 אלפיות השנייה בזמן הטעינה של הדף הוביל לעלייה במעורבות, לירידה בשיעור העזיבה ולעלייה של 0.7% בהכנסה לכל סשן.
100ms
שיפור זמני הטעינה של הדפים
0.7%
הגדלת ההכנסה לכל סשן
ההסכמה של החברה לא תמיד מובילה לשיפור בביצועים
למרות ההתעניינות הרבה בביצועים בחברה, אם הביצועים לא מוגדרים כקריטריונים למסירה של מוצרים, הם עלולים להימחק בקלות. כשעיצבנו מחדש את אתר Zalando בשנת 2020, התמקדנו בהוספת תכונות חדשות תוך שמירה על חוויית משתמש מעולה ושינוי העיצוב של האתר באמצעות גופנים מותאמים אישית וצבעים עזים יותר. עם זאת, כשהאתר והאפליקציה בעיצוב החדש היו מוכנים להשקה, מדדי המשתמשים הראשונים גילו שהגרסה החדשה איטית יותר. המדד 'הצגת תוכן ראשוני (FCP)' היה איטי יותר ב-53%, והמדד 'זמן לפעולה אינטראקטיבית' שמדדנו היה איטי יותר ב-59%.
האינטרנט ב-Zalando
אתר Zalando נוצר על ידי צוות ליבה שמפתח מסגרת, עם יותר מ-15 צוותי תכונות שתורמים מיקרו-שירותי חזית. בנוסף לתמיכה במהדורה החדשה, העברנו חלק מהאתר שלנו לארכיטקטורה מרוכזת יותר.
הארכיטקטורה הקודמת, שנקראת Mosaic, כללה דרך למדוד את ביצועי הדף באמצעות מדדים פנימיים. עם זאת, היה קשה להשוות בין מדדי הביצועים לפני ההשקה למשתמשים אמיתיים, כי לא היו לנו כלים פנימיים למעקב אחר ביצועים במעבדה. למרות הפריסה היומית, למפתחים שעובדים על שיפור הביצועים הייתה לולאת משוב של כיום אחד.
מדדי Web Vitals ו-Lighthouse מצילים את המצב
לא היינו מרוצים לגמרי מהמדדים הפנימיים שלנו, כי הם לא התאימו היטב להגדרה החדשה שלנו. חשוב מכך, הם לא התמקדו בחוויית הלקוח. עברנו למדדי הליבה לבדיקת חוויית המשתמש באתר כי הם מספקים קבוצה מרוכזת, אבל מקיפה וממוקדת-משתמש של מדדים.
כדי לשפר את הביצועים לפני ההשקה, היינו צריכים ליצור סביבה מתאימה לניסוי. כך הצלחנו לקבל מדידות שניתן לשחזר, בנוסף לתנאי בדיקה שמייצגים את האחוזון ה-90 של נתוני השטח שלנו. עכשיו מהנדסים שעובדים על שיפור הביצועים יודעים איפה למקד את המאמצים שלהם כדי להשיג את ההשפעה הגדולה ביותר. כבר השתמשנו בדוחות הביקורת של Lighthouse באופן מקומי. לכן, הגרסה הראשונה שפיתחנו הייתה שירות שמבוסס על מודול צומת של Lighthouse, שבו אפשר לבדוק שינויים מסביבת ה-staging שלנו. כך קיבלנו לולאת משוב מהימנה לגבי הביצועים, שנמשכה בערך שעה, ובעזרתה הצלחנו לשפר את הביצועים ולשמור על תאריך השקת הגרסה.
שליחת משוב על ביצועים למפתחים לגבי בקשות משיכה
לא רצינו להפסיק שם, כי רצינו לנצל את ההזדמנות לא רק להגיב לביצועים אלא גם לפעול באופן יזום. המעבר ממודול הצומת של Lighthouse לשרת Lighthouse CI (LHCI) לא היה קשה מדי. בחרנו בפתרון באירוח עצמי כדי לאפשר שילוב טוב יותר עם שירותי החברה הקיימים שלנו. אפליקציית השרת של LHCI נוצרת כקובץ אימג' של Docker, ולאחר מכן היא נפרסת באשכולות Kubernetes שלנו יחד עם מסד נתונים של PostgreSQL, ומדווחת ל-GitHub שלנו.
המסגרת שלנו כבר מספקת למפתחים משוב מסוים לגבי הביצועים – גודל החבילות של הרכיבים הושווה לערכי הסף בכל השמירה. עכשיו אנחנו יכולים לדווח על מדדי Lighthouse כבדיקות סטטוס ב-GitHub. אלה גורמים לקו צינור עיבוד הנתונים של CI להיכשל אם הם לא עומדים בתנאי הסף של הביצועים, עם קישור לדוחות המפורטים של Lighthouse, כפי שמוצג בתמונות הבאות.
הרחבת הכיסוי של הביצועים
התחלנו בגישה פרגמטית מאוד. בשלב הזה, Lighthouse פועל רק בשני הדפים החשובים ביותר שלנו: דף הבית ודף פרטי המוצר. למרבה המזל, ב-Lighthouse CI קל להרחיב את הגדרות ההרצה. צוותי פיצ'רים שעובדים על דפים ספציפיים באתר שלנו יכולים להגדיר את תבנית כתובת ה-URL והטענות הנכוֹנוּת (assertions) התואמות שלהם. בעקבות השינוי הזה, אנחנו די בטוחים שהיקף הכיסוי של נתוני הביצועים יגדל.
עכשיו אנחנו בטוחים הרבה יותר כשאנחנו מפתחים גרסאות גדולות יותר, והמפתחים יכולים ליהנות מלולאת משוב קצרה יותר לגבי ביצועי הקוד שלהם.