הורדת TBT ב-30 פעמים והמעבר ל-Next.js עזרה ל-Ecomonic Times לצמצם את ערך ה-INP כמעט ארבע פעמים, דבר שהוביל לירידה של 50% בשיעור העזיבה ולעלייה של 43% במספר הצפיות בדפים.
מהירות התגובה לאינטראקציה באתר (INP) הוא מדד להערכה של מידת הרספונסיביות של אתר לקלט של משתמשים. המשמעות של מהירות תגובה טובה היא שהדף מגיב במהירות לאינטראקציות של משתמשים. ככל שה-INP של דף מסוים נמוך יותר, כך יכולת התגובה שלו לאינטראקציות של משתמשים טובה יותר.
ההתחלה המטושטשת
כש-Google השיקה לראשונה את INP כמדד ניסיוני עם פוטנציאל להפוך לאחד ממדדי הליבה לבדיקת חוויית המשתמש באתר, הצוות של Economic Times לקח על עצמו את האתגר לפתור את הבעיה לפני שהוא יעמוד בסף הנדרש. הסיבה לכך היא שמתן חוויית משתמש ברמה עולמית הוא חיוני לערכי הליבה העסקיים שלנו.
מדד INP היה אחד מהמדדים הכי קשים שצריך לפתור עד עכשיו. בהתחלה לא היה ברור איך למדוד את ה-INP בצורה יעילה. מה שהקשה יותר היה היעדר תמיכה מהקהילה, כולל רוב הספקים של Real User Monitoring (RUM) עדיין לא תומכים בו. עם זאת, השתמשנו בכלי RUM של Google כמו דוח חוויית המשתמש ב-Chrome (CrUX), ספריית ה-JavaScript של web-vitals, וכלים נוספים שתומכים בו, שמאפשרים לנו להבין איפה עמדנו בזמן שבחנו את הנתיב שאנחנו ממשיכים מכאן. מדד ה-INP שלנו היה קרוב ל-1,000 אלפיות השנייה ברמת המקור כשהתחלנו.
דבר אחד שעלה במהלך תיקון ה-INP בשדה היה שאחד מהמדדים של שיעור ה-Lab לטירגוט הוא משך זמן החסימה הכולל (TBT). TBT כבר תועד היטב ונתמך על ידי הקהילה. למרות שכבר עמדנו בדרישות הסף של מדדי הליבה לבדיקת חוויית המשתמש באתר, לא הצלחנו להגיע לרמה גבוהה של TBT בחזית, כי כשהתחלנו להשתמש בו זה היה יותר מ-3 שניות.
מה זה TBT ואילו פעולות נקטנו כדי לשפר אותו?
TBT הוא מדד של שיעור Lab שמודד את הרספונסיביות של דף אינטרנט לקלט של משתמשים במהלך טעינת הדף. כל משימה שנמשכת יותר מ-50 אלפיות השנייה נחשבת כמשימה ארוכה, והזמן שאחרי הסף של 50 אלפיות השנייה נקרא זמן חסימה.
TBT מחושב על ידי חישוב משך הזמן הכולל של החסימה של כל המשימות הארוכות במהלך טעינת הדף. לדוגמה, אם יש שתי משימות ארוכות במהלך הטעינה, זמן החסימה ייקבע כך:
- משימה א' נמשכת 80 אלפיות השנייה (30 אלפיות שנייה יותר מ-50 אלפיות שנייה).
- משימה ב' נמשכת 100 אלפיות השנייה (50 אלפיות שנייה יותר מ-50 אלפיות שנייה).
המדד 'TBT' בדף יהיה: 80 אלפיות השנייה (30 + 50). ככל ש-TBT נמוך יותר, כך גם ה-TBT מתאים יותר ל-INP.
הנה השוואה מהירה בין נתוני ה-TBT שלנו לפני ואחרי שנקטנו כדי לשפר אותם:
צמצום העבודה על ה-thread הראשי
ה-thread הראשי של הדפדפן מטפל בכל ההיבטים, החל מניתוח HTML, בניית ה-DOM, ניתוח CSS והחלת סגנונות, וגם הערכה וביצוע של JavaScript. ה-thread הראשי מטפל גם באינטראקציות של משתמשים – קליקים, הקשה והקשות על מקשים. אם ה-thread הראשי עוסק בפעולות אחרות, יכול להיות שהוא לא יגיב בצורה יעילה לקלט של משתמשים, ויכול להיות שחוויית המשתמש תהיה בעייתית.
זו הייתה המשימה הקשה ביותר עבורנו, כי יש לנו אלגוריתמים משלנו לזיהוי של זהות המשתמש לצורך הצגת מודעות, על סמך סטטוס המינוי וסקריפטים של צד שלישי לצורך בדיקות A/B, ניתוח נתונים ועוד.
בהתחלה נקטנו צעדים קטנים, כמו ביטול התעדוף של טעינה של נכסים עסקיים פחות חשובים. שנית, השתמשנו ב-requestIdleCallback לעבודה לא קריטית, שיכולה לעזור להקטין את TBT.
if ('requestIdleCallback' in window) {
this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}
מומלץ לציין זמן קצוב לתפוגה כשמשתמשים ב-requestIdleCallback, כי הוא מוודא שאם הזמן הנתון עבר והקריאה החוזרת לא נקראה כבר, היא תבצע את הקריאה החוזרת מיד אחרי הזמן הקצוב לתפוגה.
קיצור זמן ההערכה של הסקריפט
בנוסף, הטעינה הדרגתית של ספריות צד שלישי מתבצעת באמצעות רכיבים נטענים. בנוסף, הסרנו JavaScript ו-CSS שאינם בשימוש על ידי יצירת פרופיל הדף באמצעות כלי הכיסוי ב'כלי הפיתוח ל-Chrome'. הוא עזר לנו לזהות אזורים שבהם היה צורך ברעידת עץ כדי לשלוח פחות קוד בזמן טעינת הדף, וכתוצאה מכך להפחית את גודל החבילה ההתחלתי של האפליקציה.
הקטנת ה-DOM
לפי Lighthouse, יחידות DOM גדולות מגדילות את השימוש בזיכרון, גורמות לחישובים מחדש של סגנונות ומייצרות זרימה חוזרת של פריסות יקרות.
צמצמנו את מספר צומתי ה-DOM בשתי דרכים:
- בשלב הראשון, עיבדנו את האפשרויות בתפריט לפי בקשת המשתמש (בלחיצה). היא הקטינה את גודל ה-DOM ב-1,200 צמתים.
- שנית, אנחנו טוענים ווידג'טים פחות חשובים באופן הדרגתי.
בעקבות כל המאמצים האלה, הקטנו באופן משמעותי את TBT, וה-INP הופחת בהתאם בכמעט 50%:
בשלב הזה, כמעט אזלו לנו ניצחונות קלים כדי לצמצם עוד יותר את TBT (ואת INP באמצעות שרת proxy), אבל ידענו שיש לנו מקום רב לשיפור. לכן החלטנו לשדרג את הגרסה הקבועה של ממשק המשתמש לגרסה האחרונה של React יחד עם Next.js, כדי לשפר את השימוש בהוקים (hooks) וכך להימנע מעיבוד מחדש מיותר של הרכיבים.
בעקבות עדכונים תכופים יותר ונפח תנועה קטן יחסית בהשוואה לחלקים אחרים באתר, התחלנו להעביר את דפי הנושאים אל Next.js. השתמשנו גם ב-PartyTown כדי להעביר לעובדי אינטרנט עוד עבודה של תהליכונים כבדים (thread) ראשי, יחד עם שיטות כמו requestIdleCallBack לדחייה של משימות לא קריטיות.
איך שיפור מדד INP עזר ל-The Economic Times?
TBT ו-INP נוכחיים במקור
בזמן פרסום הפוסט הזה, זמן האופטימיזציה של המקור שלנו היה 120 אלפיות השנייה, פחות מ-3,260 אלפיות שנייה כשהתחלנו במאמצי האופטימיזציה. באופן דומה, ערך ה-INP של המקור שלנו היה 257 אלפיות השנייה לאחר מאמצי האופטימיזציה, פחות מ-1,000 אלפיות השנייה.
מגמת CrUX ב-INP
התנועה שמתקבלת בדפי נושא מייצגת חלק קטן יותר באופן משמעותי מהתנועה הכוללת. לכן הוא היה המקום האידיאלי לעריכת ניסויים. התוצאות של CrUX והתוצאות העסקיות היו מעודדות מאוד, והובילו לכך הרחבנו את המאמצים שלנו באתר כולו ולהפיק תועלת נוספת.
ניתוח TBT של Akamai mPulse
אנחנו משתמשים ב-Akamai mPulse כפתרון ה-RUM שלנו, שמודד את TBT בשטח. שמנו לב בירידה עקבית במדד TBT, שמיפוי בבירור לתוצאות המאמצים שלנו לצמצום ה-INP. כמו שאפשר לראות בצילום המסך למטה, ערכי TBT צנחו בסופו של דבר מ-5 שניות בערך ל-200 אלפיות השנייה בערך בשדה.
תוצאה עסקית
באופן כללי, המאמצים שלנו להפחית את TBT פי 30 יחד עם המעבר ל-Next.js עזרו לנו להפחית את INP כמעט פי 4, ובסופו של דבר הובילו לירידה של 50% בשיעור העזיבה ולעלייה של 43% בצפיות בדפים בדפי נושא.
סיכום
לסיכום, INP עזר באופן נרחב לקבוע בעיות בביצועים בסביבת זמן הריצה בחלקים באתר של Economic Times. הוא הוכיח את עצמו כאחד מהמדדים היעילים ביותר ליצירת השפעה חיובית על התוצאות העסקיות. לאור הנתונים המעודדים מאוד שזיהינו כתוצאה מהמאמץ הזה, יש לנו מוטיבציה להרחיב את מאמצי האופטימיזציה לאזורים אחרים באתר שלנו ולהפיק תועלת נוספת.