אופטימיזציה של האינטראקטיביות של דפי פרטי המוצרים עבור ירידה של 90% ב-FID פוטנציאלי מקסימלי ב-Lighthouse ושיפור של 9% ב-FID בדוח חוויית המשתמש ב-Chrome.
Mercado Libre היא הסביבה העסקית הגדולה ביותר למסחר אלקטרוני ולתשלומים באמריקה הלטינית. האתר פועל ב-18 מדינות, והוא מוביל בשוק בברזיל, במקסיקו ובארגנטינה (על סמך מבקרים ייחודיים וצפיות בדפים).
החברה מתמקדת בביצועי אתרים במשך תקופה ארוכה, אבל לאחרונה היא הקימה צוות שעוקב אחרי הביצועים ומבצע אופטימיזציות על חלקים שונים באתר.
המאמר הזה מסכם את העבודה של Guille Paz, Pablo Carminatti ו-OlehBurkhay מצוות הארכיטקטורה בחזית של Mercado Libre, כדי לבצע אופטימיזציה של אחד מהמדדים הבסיסיים של חוויית המשתמש (Core Web Vitals): עיכוב בקלט ראשון (FID) ובשרת ה-proxy שלו לשיעור ה-Lab, זמן חסימה כולל (TBT).
90%
צמצום של FID פוטנציאלי מקסימלי ב-Lighthouse
9%
יותר משתמשים חושבים ש-FID הוא 'מהיר' ב-CrUX
משימות ארוכות, השהיה לאחר קלט ראשון וזמן חסימה כולל
הרצה של קוד JavaScript יקר יכולה להוביל למשימות ארוכות, כלומר משימות שרצות יותר מ-50 אלפיות השנייה ב-thread הראשי של הדפדפן.
FID (עיכוב בקלט ראשון) מודד את הזמן שעובר מהאינטראקציה הראשונה של משתמש עם דף (למשל, לחיצה על קישור) עד לרגע שבו הדפדפן יכול להתחיל לעבד אירועים בתגובה לאותה אינטראקציה. באתר שמפעיל קוד JavaScript יקר כנראה יהיו כמה משימות ארוכות, שבסופו של דבר ישפיעו לרעה על FID.
כדי לספק חוויית משתמש טובה, אתרים צריכים לכלול עיכוב של פחות מ-100 אלפיות השנייה
בקלט הראשון:
למרות שבאתר של Mercado Libre היו ביצועים טובים ברוב הקטעים, הם גילו בדוח חוויית המשתמש ב-Chrome שה-FID של הדפים של פרטי המוצר היה נמוך. על סמך המידע הזה, הם החליטו למקד את המאמצים שלהם בשיפור האינטראקטיביות של דפי המוצרים באתר.
הדפים האלה מאפשרים למשתמשים לבצע אינטראקציות מורכבות, כך שהמטרה הייתה אופטימיזציה של האינטראקטיביות, בלי להפריע לפונקציונליות רבת הערך.
מדידת האינטראקטיביות של דפים של פרטי מוצרים
יש צורך במשתמש אמיתי ב-FID, ולכן לא ניתן למדוד אותו בשיעור ה-Lab. עם זאת, המדד Total Block Time (TBT) ניתן למדידה במעבדה, משתלב היטב עם FID בשדה ומזהה גם בעיות שמשפיעות על האינטראקטיביות.
לדוגמה, במעקב הבא, למרות שהזמן הכולל שהוקדש להרצת משימות ב-thread הראשי הוא 560 אלפיות השנייה, רק 345 אלפיות השנייה מהזמן הזה נחשבים לזמן החסימה הכולל (סך החלקים בכל משימה שחורגים מ-50 אלפיות השנייה):
ב-Mercado Libre לקחנו את TBT כמדד proxy במעבדה, כדי למדוד ולשפר את האינטראקטיביות של דפי פרטי מוצרים בעולם האמיתי.
הנה הגישה הכללית שלהם:
- אפשר להשתמש ב-WebPageTest כדי לקבוע בדיוק אילו סקריפטים השאירו את ה-thread הראשי עמוס במכשיר אמיתי.
- השתמשו ב-Lighthouse כדי לקבוע את ההשפעה של השינויים במדד השהיה פוטנציאלית מקסימלית לאחר קלט ראשון (FID פוטנציאלי מקסימלי).
שימוש ב-WebPageTest כדי להציג משימות ארוכות
WebPageTest (WPT) הוא כלי לביצועי אינטרנט שמאפשר להריץ בדיקות במכשירים אמיתיים במיקומים שונים ברחבי העולם.
ב-Mercado Libre השתמשו ב-WPT כדי לשחזר את החוויה של המשתמשים, על ידי בחירת סוג מכשיר ומיקום שדומים לאלה של משתמשים אמיתיים. באופן ספציפי, החברה בחרה במכשיר Moto 4G וב-Dulles, וירג'יניה, כי רצתה להעריך את החוויה של משתמשי Mercado Libre במקסיקו. בחברת Mercado Libre בחנו את תצוגת השרשור העיקרית של WPT, וזיהו מספר משימות ארוכות ברציפות שחסמו את ה-thread הראשי למשך 2 שניות:
הם ניתחו את ה-Waterfall התואם ומצאו שחלק משמעותי משתי השניות האלה הגיע ממודול ניתוח הנתונים. גודל החבילה הראשי של האפליקציה היה גדול (950KB) והניתוח, ההידור והביצוע שלו היה ארוך מדי.
שימוש ב-Lighthouse כדי לקבוע את הערך המקסימלי של FID
ב-Lighthouse אי אפשר לבחור בין מכשירים ומיקומים שונים, אבל הוא כלי שימושי מאוד לאבחון אתרים ולקבלת המלצות לשיפור הביצועים.
כשהפעילו את Lighthouse בדפים של פרטי מוצרים, ב-Mercado Libre מצאו שה-FID הפוטנציאלי המקסימלי היה המדד היחיד שסומן באדום, עם ערך של 1710 אלפיות השנייה.
על סמך הנתונים האלה, Mercado Libre הגדירו יעד לשיפור ציון ה-FID הפוטנציאלי המקסימלי בכלי מעבדה כמו Lighthouse ו-WebPageTest, מתוך הנחה שהשיפורים האלה ישפיעו על המשתמשים האמיתיים שלהם, ולכן הם יופיעו בכלי מעקב אמיתיים של משתמשים, כמו הדוח 'חוויית המשתמש ב-Chrome'.
אופטימיזציה למשימות ארוכות
איטרציה ראשונה
על סמך דוח ה-thread הראשי, ב-Mercado Libre הגדירה יעד לאופטימיזציה של שני המודולים שמריצים קוד יקר.
הצוות התחיל לבצע אופטימיזציה של הביצועים של מודול המעקב הפנימי. המודול הזה הכיל משימה עמוסה במעבד (CPU) שלא הייתה קריטית להצלחת המודול, ולכן ניתן היה להסיר אותה בבטחה. התוצאה הייתה ירידה של 2% ב-JavaScript בכל האתר.
לאחר מכן, הצוות התחיל לעבוד על שיפור הגודל הכללי של החבילה:
ב-Mercado Libre השתמשו ב-webpack-bundle-analyzer כדי לזהות הזדמנויות לאופטימיזציה:
- בהתחלה היה צורך במודול Lodash מלא. האפשרות הזו הוחלפה בדרישה לכל שיטה כדי לטעון רק קבוצת משנה של Lodash במקום את הספרייה כולה, ולהשתמש בה בשילוב עם lodash-webpack-פלאגין כדי לכווץ את Lodash אפילו יותר.
היא יישמה גם את האופטימיזציות הבאות של Babel:
- שימוש ב-@babel/plugin-transform-runtime כדי לעשות שימוש חוזר בעוזרים של Babel לאורך הקוד, וכדי להקטין את גודל החבילה באופן משמעותי.
- שימוש ב-babel-plugin-search-and-replace כדי להחליף אסימונים בזמן ה-build כדי להסיר קובץ תצורה גדול בתוך החבילה הראשית.
- כשמוסיפים את babel-plugin-transform-react-remove-prop-types, מסירים את סוגי האביזרים כדי לחסוך בייטים נוספים.
בעקבות האופטימיזציה הזו, גודל החבילה הוקטן בערך ב-16%.
מדידת ההשפעה
השינויים הפחיתו את כמות המשימות הארוכות שהצליחו Mercado Libre, משתי שניות לשנייה אחת:
ב-Lighthouse הבחינו בירידה של 57% במדד 'העיכוב הפוטנציאלי המקסימלי לאחר קלט ראשון':
איטרציה שנייה
הצוות המשיך לחקור לעומק משימות ארוכות כדי למצוא שיפורים עתידיים.
על סמך המידע הזה היא החליטה להטמיע את השינויים הבאים:
- המשיכו להקטין את גודל החבילה הראשית כדי לבצע אופטימיזציה של זמן ההידור והניתוח (למשל, על ידי הסרת יחסי תלות כפולים בין המודולים השונים).
- אפשר להשתמש בפיצול קוד ברמת הרכיב כדי לחלק את JavaScript לחלקים קטנים יותר ולאפשר טעינה חכמה יותר של הרכיבים השונים.
- כדאי לדחות את התייבשות הרכיבים כדי לאפשר שימוש חכם יותר ב-thread הראשי. השיטה הזו נקראת בדרך כלל הידרציה חלקית.
מדידת ההשפעה
מעקב WebPageTest שהתקבל הראה חלקים קטנים עוד יותר של הפעלת JS:
כמו כן, זמן ה-FID הפוטנציאלי המקסימלי ב-Lighthouse צומצם ב-60%נוספים:
הצגה חזותית של ההתקדמות עבור משתמשים אמיתיים
כלים לבדיקת מעבדה כמו WebPageTest ו-Lighthouse הם דרך נהדרת לחזור על פתרונות במהלך הפיתוח, אבל המטרה האמיתית היא לשפר את החוויה של משתמשים אמיתיים.
הדוח על חוויית המשתמש ב-Chrome מספק מדדים של חוויית המשתמש ביחס לאופן שבו משתמשי Chrome חווים יעדים פופולריים באינטרנט. כדי לקבל את הנתונים מהדוח, אפשר להפעיל שאילתות ב-BigQuery, ב-PageSpeedInsights או ב-CrUX API.
לוח הבקרה של CrUX מציג בקלות את ההתקדמות של מדדי ליבה:
השלבים הבאים
ביצועי אתרים הם אף פעם לא משימה שמסתיימת, וב-Mercado Libre מבינים את הערך שהאופטימיזציות האלה תורמות למשתמשים. החברה ממשיכה לבצע מספר אופטימיזציות באתר כולו, כולל שליפה מראש (prefetch) של דפי כרטיסי מוצר, אופטימיזציה של תמונות ועוד, אבל היא ממשיכה להוסיף שיפורים לדפים של כרטיסי מוצר כדי לצמצם את זמן החסימה הכולל (TBT) ובאמצעות FID של שרת proxy ועוד. האופטימיזציות האלה כוללות:
- חזרה על פתרון פיצול הקוד.
- שיפור הביצוע של סקריפטים של צד שלישי.
- שיפורים מתמשכת בקיבוץ נכסים ברמת ה-bundler (חבילת אינטרנט).
ב-Mercado Libre יש תמונה מקיפה של הביצועים. לכן, בזמן שהם ממשיכים לבצע אופטימיזציה של האינטראקטיביות באתר, הם התחילו גם להעריך הזדמנויות לשיפור בשני מדדי הליבה לבדיקת חוויית המשתמש באתר הקיימים: LCP (LCP (LCP) (LCP (LCP) ו-CLS (Cumulative Layout Shift) ועוד.