איך Trendsol הפחיתה את INP ב-50% וכתוצאה מכך עלתה עלייה של 1% בשיעור הקליקים

מקרה לדוגמה שמתאר תהליך עבודה מפורט לניפוי באגים ולשיפור ב-INP ב-React שבו נעשה שימוש ב-Trendyol באמצעות כלים של Google כמו PageSpeed תובנות (PSI), כלי פיתוח ל-Chrome ו-API של scheduler.yield.

Mustafa Birinci

Gilberto Cocchi

Thierno Thiam

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

Trendyol היא פלטפורמת מסחר אלקטרוני שיש לה כ-30 מיליון לקוחות עם 240,000 מוכרים, מה שהוביל אותנו להיות העסק הראשון בטורקיה עם שווי של יותר מ-10 מיליארד דולר, ואחת מפלטפורמות המסחר האלקטרוני המובילות העולם.

כדי להשיג את המטרה שלה לספק חוויית משתמש טובה ככל האפשר בקנה מידה רחב תוך שמירה על גמישות התוכן ועבודה עם גרסה ישנה יותר של מגיבים ו-Trendyol התמקד באינטראקציה עד השלב הבא (INP) כמדד מרכזי אם הם ישפרו. מקרה לדוגמה שמתאר את המסע של Trendsol לשיפור INP במדד PLP, כתוצאה מירידה של 50% במדד INP ו-1% עלייה בתוצאות החיפוש המדד העסקי של התוצאות.

תהליך החקירה של Trendsol ב-INP

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

המסע של טרנדים לשיפור INP ב-PLP התחיל בניתוח יסודי את חוויית המשתמש לפני ביצוע שיפורים. בהתבסס על דוח PSI, חוויית המשתמש האמיתית של ה-PLP הייתה ב-INP של 963 אלפיות השנייה לנייד, כפי שמוצג באיור הבא.

כדי להבטיח תגובה טובה, בעלי אתרים צריכים להשגיח על מדד INP מתחת או 200 אלפיות שנייה, כלומר, באותו זמן, ה-INP של טרנדים 'איטי' טווח.

למרבה המזל, PSI מספק את שני נתוני השדות עבור דפים שכלולים במשתמש Chrome דוח חוויית השימוש (CrUX) ונתוני אבחון מפורטים של שיעור Lab. צפייה בשיעור ה-Lab בדיקת זמן הביצוע של JavaScript ב-Lighthouse הציעה סקריפט search-result-v2 תופס את ה-thread הראשי יותר זמן מאשר אחר הסקריפטים שבדף.

כדי לזהות צווארי בקבוק בעולם האמיתי, השתמשנו בחלונית הביצועים ב-Chrome כלי פיתוח כדי לפתור בעיות בחוויית השימוש ב-PLP ולזהות את המקור בעיה. אמולציה של הביצועים בנייד עם האטה פי 4 של המעבד (CPU) בכלי הפיתוח ל-Chrome גילתה משימה באורך 700-900 אלפיות שנייה ב-thread הראשי. אם העמודה שה-thread נמשך במשימות אחרות במשך יותר מ-50 אלפיות השנייה, יכול להיות שהוא לא יכול להגיב בזמן לקלט של משתמשים, וכתוצאה מכך חוויית המשתמש.

המשימה הארוכה ביותר נגרמה על ידי קריאה חוזרת (callback) של Intersection Observer API סקריפט של תוצאות חיפוש בתוך רכיב React. בשלב הזה התחלנו לפרק את המשימה הארוכה לחלקים קטנים כדי לתת לדפדפן הזדמנויות להגיב לעבודה בעדיפות גבוהה יותר, כולל אינטראקציות עם משתמשים.

מסתבר שהשימוש בפעולה setState שמפעיל את התגובה לעיבוד חוזר בתוך הקריאה החוזרת (callback) של 'צומת הצופים' יש עלות גבוהה, דבר שעלול להיות בעייתי למכשירים פשוטים על ידי העברת ה-thread הראשי ארוך מדי.

אחת השיטות שבהן המפתחים השתמשו כדי לחלק משימות למשימות קטנות יותר כוללת setTimeout. השתמשנו בשיטה הזו כדי לדחות את הביצוע של שיחה אחת (setState) למשימה נפרדת. למרות ש-setTimeout מאפשר דחייה הפעלת JavaScript, היא לא מספקת שליטה על העדיפות. הובילה לכך להצטרף לגרסת המקור לניסיון של scheduler.yield כדי להבטיח המשך ביצוע הסקריפט שלנו לאחר שחזרה ל-thread הראשי:

/*
* Yielding method using scheduler.yield, falling back to setTimeout:
*/
async function yieldToMain() {
  if('scheduler' in window && 'yield' in scheduler) {
    return await scheduler.yield();
  }

  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

/*
* Yielding to the main thread before changing the state of the component:
*/
const observer = new IntersectionObserver((entries) => {
  entries.forEach(handleIntersection);
  const maxNumberOfEntries = Math.max(...this.intersectingEntries);

  if (Number.isFinite(maxNumberOfEntries)) {
    await this.yieldToMain();

    this.setState({ count: maxNumberOfEntries });
  }
}, { threshold: 0.5 });

הוספת שיטת התפוקה הזו לקוד ה-PLP הובילה לשיפור ב-INP, שהמשימה הארוכה ביותר פוצלה לסדרה של משימות קטנות יותר, עבודה בעדיפות גבוהה יותר - כגון אינטראקציות של משתמשים ועבודות רינדור נוספות - קיימים מוקדם יותר ממה שהם היו יכולים לעשות.

שימו לב ש-Trendyol משתמש ב-PuzzleJs framework כדי להטמיע מיקרו-חזית באמצעות React v16.9.0. עם React 18, אותם ביצועים יכולים להיות הושג, אך מכמה סיבות, Trends לא יכול לשדרג בשלב זה בזמן האימון.

תוצאות עסקיות

כדי למדוד את ההשפעה של שיפור ה-INP שהוטמע, הפעלנו בדיקת A/B לראות איך המדדים העסקיים הושפעו. באופן כללי, השינויים ב-PLP הובילו עם שיפור משמעותי, כולל ירידה של 50% במדד INP וירידה של 1% עלייה בשיעורי הקליקים מדף כרטיסי המוצר אל דף פרטי המוצר לכל סשן של משתמש. באיור הבא אפשר לראות את השיפור ב-INP PLP לאורך זמן:

סיכום

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

לבצע מדי פעם תקלה ל-thread הראשי כדי לתת לדפדפן עוד הזדמנויות לביצוע עבודה דחופה יהפכו את האתר שלך לרספונסיבי יותר, לכך שהלקוחות שלכם נהנים מחוויית משתמש טובה יותר. ממשקי API חדשים יותר לתזמון כמו scheduler.yield(), קל יותר לבצע את המשימה הזו.

תודה מיוחדת לג'רמי וגנר, בארי פולארד וחוסיין ג'רדה מ: Google וצוות ההנדסה של טרנדים על התרומה שלהם למאמצים האלה.