מסע לפתרון INP של ה-EEA

הורדת TBT ב-30 פעמים והמעבר ל-Next.js עזרה ל-Ecomonic Times לצמצם את ערך ה-INP כמעט ארבע פעמים, דבר שהוביל לירידה של 50% בשיעור העזיבה ולעלייה של 43% במספר הצפיות בדפים.

Daya Ram Yadav
Daya Ram Yadav
Saurabh Rajpal
Saurabh Rajpal

מהירות התגובה לאינטראקציה באתר (INP) הוא מדד להערכה של מידת הרספונסיביות של אתר לקלט של משתמשים. מהירות תגובה טובה פירושה שהדף מגיב במהירות לאינטראקציות של משתמשים. ככל שה-INP של דף מסוים נמוך יותר, כך יכולת התגובה שלו לאינטראקציות של משתמשים טובה יותר.

ערכי INP טובים הם 200 אלפיות שנייה או פחות, ערכים נמוכים הם יותר מ-500 אלפיות שנייה, וכל מה שביניהם צריך לשפר.

ההתחלה המטושטשת

כש-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 שלנו לפני ואחרי שנקטנו כדי לשפר אותם:

תמונה מורכבת של משימות ארוכות במהלך ההפעלה, כמו שהיא מוצגת בחלונית הביצועים של כלי הפיתוח ל-Chrome, ודוח של מדדי הדף. ה-thread הראשי חסום במהלך טעינת הדף למשך 3,260 אלפיות השנייה.
ה-thread הראשי במהלך ההפעלה לפני אופטימיזציה של TBT. ה-TBT הוא 3,260 אלפיות השנייה.
תמונה מורכבת של משימות ארוכות במהלך ההפעלה, כמו שהיא מוצגת בחלונית הביצועים של כלי הפיתוח ל-Chrome, ודוח של מדדי הדף. ה-thread הראשי חסום במהלך טעינת הדף למשך 120 אלפיות השנייה.
ה-thread הראשי במהלך ההפעלה אחרי אופטימיזציה של TBT. ההגדרה TBT היא 120 אלפיות השנייה.

צמצום העבודה על ה-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. הוא עזר לנו לזהות אזורים שבהם היה צורך ברעידת עץ כדי לשלוח פחות קוד בזמן טעינת הדף, וכתוצאה מכך להפחית את גודל החבילה ההתחלתי של האפליקציה.

צילום מסך של כלי הכיסוי בכלי הפיתוח ל-Chrome. כאן הכלי מציג חלקים שלא נמצאים בשימוש בקובצי JavaScript ו-CSS במהלך טעינת הדף.

הקטנת ה-DOM

לפי Lighthouse, יחידות DOM גדולות מגדילות את השימוש בזיכרון, גורמות לחישובים מחדש של סגנונות ומייצרות זרימה חוזרת של פריסות יקרות.

צילום מסך של בדיקת גודל ה-DOM ב-Lighthouse. מספר רכיבי ה-DOM שדווחו הוא 2,706 רכיבים.

צמצמנו את מספר צומתי ה-DOM בשתי דרכים:

  • בשלב הראשון, עיבדנו את האפשרויות בתפריט לפי בקשת המשתמש (בלחיצה). היא הקטינה את גודל ה-DOM ב-1,200 צמתים.
  • שנית, אנחנו טוענים ווידג'טים פחות חשובים באופן הדרגתי.

בעקבות כל המאמצים האלה, הקטנו באופן משמעותי את TBT, וה-INP הופחת בהתאם בכמעט 50%:

צילום מסך של ביקורת INP ב-CrUX. ערך ה-INP של הדף הוא 539 אלפיות השנייה, והוא חורג מהמדד 'חלש' לסף מינימום.

בשלב הזה, כמעט אזלו לנו ניצחונות קלים כדי לצמצם עוד יותר את 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 אלפיות השנייה.

צילום מסך של ביקורת INP ב-CrUX. ערך ה-INP של הדף הוא 257 אלפיות השנייה, כלומר במסגרת 'נדרש שיפור' במחירי סף.

מגמת CrUX ב-INP

התנועה שמתקבלת בדפי נושא מייצגת חלק קטן יותר באופן משמעותי מהתנועה הכוללת. לכן הוא היה המקום האידיאלי לעריכת ניסויים. התוצאות של CrUX והתוצאות העסקיות היו מעודדות מאוד, והובילו לכך הרחבנו את המאמצים שלנו באתר כולו ולהפיק תועלת נוספת.

צילום מסך של התפלגויות INP כפי שהן מוצגות ב-CrUX במשך ארבעה חודשים, החל מיולי 2022 ומסתיים באוקטובר 2022. ערכים בתוך 'איטי' ו'דרוש שיפור' ערכי הסף ירדו במידה מסוימת, בעוד שהערכים בטווח 'טוב' סף החיוב עלה.

ניתוח TBT של Akamai mPulse

אנחנו משתמשים ב-Akamai mPulse כפתרון ה-RUM שלנו, שמודד את TBT בשטח. שמנו לב בירידה עקבית במדד TBT, שמיפוי בבירור לתוצאות המאמצים שלנו לצמצום ה-INP. כמו שאפשר לראות בצילום המסך למטה, ערכי TBT צנחו בסופו של דבר מ-5 שניות בערך ל-200 אלפיות השנייה בערך בשדה.

צילום מסך של תרשים ב-Akamai mPulse שבו מוצגת ירידה ב-TBT במהלך כחודש.

תוצאה עסקית

באופן כללי, המאמצים שלנו להפחית את TBT פי 30 יחד עם המעבר ל-Next.js עזרו לנו להפחית את INP כמעט פי 4, ובסופו של דבר הובילו לירידה של 50% בשיעור העזיבה ולעלייה של 43% בצפיות בדפים בדפי נושא.

צילום מסך של Google Analytics שמשווה בין צפיות בדף לבין שיעור העזיבה. בעקבות האופטימיזציות שבוצעו ל-INP באתר The Economic Times, התקבלה ירידה של 50% בשיעור העזיבה ועלייה של 43% במספר הצפיות בדפים.

סיכום

לסיכום, INP עזר באופן נרחב לקבוע בעיות בביצועים בסביבת זמן הריצה בחלקים באתר של Economic Times. הוא הוכיח את עצמו כאחד מהמדדים היעילים ביותר ליצירת השפעה חיובית על התוצאות העסקיות. לאור הנתונים המעודדים מאוד שזיהינו כתוצאה מהמאמץ הזה, יש לנו מוטיבציה להרחיב את מאמצי האופטימיזציה לאזורים אחרים באתר שלנו ולהפיק תועלת נוספת.