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