צוות האינטרנט ב-Zalando גילה שהשילוב של Lighthouse CI איפשר גישה יזומה לביצועים, ובדיקות סטטוס אוטומטיות מאפשרות להשוות את ההתחייבות הנוכחית להסתעפות הראשית, על מנת למנוע רגרסיות של ביצועים.
Zalando היא פלטפורמת האופנה הווירטואלית המובילה באירופה, עם יותר מ-35 מיליון לקוחות פעילים. בפוסט הזה נסביר למה התחלנו להשתמש ב-Lighthouse CI, בקלות ההטמעה וביתרונות לצוות שלנו.
אנחנו ב-Zalando מכירים את הקשר בין ביצועי האתר לבין ההכנסות. בעבר, בדקנו איך הארכה מלאכותית של זמן טעינה בדפי קטלוג השפיעה על שיעורי העזיבה, על שיעורי ההמרות ועל ההכנסה למשתמש. התוצאות היו ברורות. שיפור בזמן הטעינה של דף של 100 אלפיות השנייה הוביל להגברת המעורבות, עם שיעור עזיבה נמוך יותר ועלייה של 0.7% בהכנסה לכל סשן.
100אלפיות שנייה
שיפור בזמן הטעינה של דף
0.7%
הכנסה מוגדלת לכל סשן
הרכישה של החברה לא תמיד משקפת ביצועים
למרות העלייה החדה בביצועים בתוך החברה, אם הביצועים לא מוגדרים כקריטריון למשלוח מוצרים, הם עלולים לפגוע בקלות בביצועים. כשעיצבנו מחדש את האתר של Zalando ב-2020, התמקדנו ביצירת תכונות חדשות תוך שמירה על חוויית משתמש מעולה והוספת מתיחת פנים לאתר, עם גופנים בהתאמה אישית וצבעים עזים יותר. עם זאת, כשהאתר והאפליקציה שעוצבו מחדש היו מוכנים להשקה, המדדים של ראשוני המשתמשים העלו שהגרסה החדשה הייתה איטית יותר. הצגת התוכן הראשוני (Contentful Paint) הייתה איטית יותר ב-53%, ומדד 'זמן עד לפעילות מלאה' דיווח לאט יותר ב-59%.
האינטרנט ב-Zalando
האתר של Zalando נוצר על ידי צוות ליבה שמפתח מסגרת, שכולל יותר מ-15 צוותי תכונות שתורמים למיקרו-שירותים (microservice). במהלך התמיכה בגרסה החדשה, העברנו גם חלק מהאתר לארכיטקטורה ריכוזית יותר.
הארכיטקטורה הקודמת שנקראה פסיפס כללה דרך למדוד את ביצועי הדפים באמצעות מדדים פנימיים. עם זאת, היה קשה להשוות מדדי ביצועים לפני ההשקה למשתמשים אמיתיים, כי לא היו לנו כלים פנימיים למעקב אחרי הביצועים של שיעור ה-Lab. למרות הפריסה כל יום, הייתה לולאת משוב במשך בערך יום אחד למפתחים שעבדו על שיפורי ביצועים.
בעזרת Web Vitals ומגדלור להצלה
לא היינו מרוצים לגמרי מהמדדים הפנימיים שלנו כי הם לא התאמנו היטב להגדרה החדשה שלנו. וחשוב מכך, הם לא התמקדו בחוויית הלקוח. עברנו למדדי הליבה לבדיקת חוויית המשתמש באתר, מאחר שהם סיפקו קבוצת מדדים מרוכזת אך מקיפה וממוקדת במשתמשים.
כדי לשפר את הביצועים לפני ההשקה, היה עלינו ליצור סביבת Lab מתאימה. הם מספקים מדידות הניתנות לשחזור, בנוסף לתנאי הבדיקה שמייצגים את נתוני השטח באחוזון ה-90 שלנו. עכשיו, המהנדסים שעובדים על שיפור הביצועים ידעו איפה למקד את המאמצים כדי להשיג את התוצאות הכי טובות. כבר השתמשנו בדוחות ביקורת של Lighthouse באופן מקומי. בשלב הראשון, פיתחנו שירות שמבוסס על מודול הצומת של Lighthouse, שבו אפשר לבדוק את השינויים מסביבת ה-Staging. כך קיבלנו לולאת משוב אמינה על ביצועים באורך של כשעה, שאפשרה לנו להשיג ביצועים ברמה זהה ולשמור את הגרסה שלנו!
שליחת משוב על ביצועים למפתחים לגבי בקשות משיכה
לא רצינו לעצור שם, מכיוון שרצינו לנצל את ההזדמנות לא רק להגיב לשיפור הביצועים, אלא גם באופן יזום. לא היה קשה לעבור ממודול הצומת של Lighthouse אל שרת Lighthouse CI (LHCI). בחרנו בפתרון באירוח עצמי כדי לספק לנו שילוב טוב יותר עם שירותי החברה הקיימים שלנו. אפליקציית שרת ה-LHCI שלנו בנויה כתמונת Docker, ולאחר מכן נפרסת באשכול Kubernetes יחד עם מסד נתונים PostgreSQL, ומדווחת ל-GitHub.
המסגרת שלנו כבר סיפקה למפתחים משוב על הביצועים – בוצעה השוואה בין גודל החבילות של הרכיבים לבין ערכי הסף בכל התחייבות. עכשיו אנחנו יכולים לדווח על מדדי Lighthouse כבדיקות הסטטוס של GitHub. הבעיות האלה גורמות לכשל של צינור עיבוד הנתונים של ה-CI אם הוא לא עומד בספי הביצועים, עם קישור לדוחות המפורטים של Lighthouse כמו שאפשר לראות בתמונות הבאות.
הרחבת כיסוי הביצועים
התחלנו בגישה פרגמטית מאוד. בשלב זה, Lighthouse פועל רק בשניים מהדפים החשובים ביותר שלנו: דף הבית ודף פרטי המוצר. למרבה המזל, בעזרת Lighthouse CI אפשר להרחיב בקלות את הגדרות ההרצה. צוותי תכונות שעובדים בדפים ספציפיים באתר שלנו יכולים להגדיר את דפוסי כתובות האתרים ואת טענות הנכונות שלהם. לאחר מכן, אנחנו בטוחים שכיסוי הביצועים שלנו יגדל.
עכשיו אנחנו בטוחים יותר בבנייה של גרסאות גדולות יותר, ומפתחים יכולים ליהנות מלולאת משוב קצרה הרבה יותר על ביצועי הקוד שלהם.