מקרה לדוגמה שמתאר תהליך עבודה מפורט לניפוי באגים ולשיפור ב-INP
ב-React שבו נעשה שימוש ב-Trendyol באמצעות כלים של Google כמו PageSpeed
תובנות (PSI), כלי פיתוח ל-Chrome ו-API של scheduler.yield
.
שני הרכיבים הקריטיים של כל אתר מסחר אלקטרוני הם דף פרטי המוצר (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 של Trendsol על סמך קריאת המידע של CrUX ב-PageSpeed Insights. מדד ה-INP של טרנדים נכון ל-5 בספטמבר 2023 היה 963 אלפיות השנייה, טווח.](https://web.dev/static/case-studies/trendyol-inp/image/fig-1.png?authuser=9&hl=he)
כדי להבטיח תגובה טובה, בעלי אתרים צריכים להשגיח על מדד INP מתחת או 200 אלפיות שנייה, כלומר, באותו זמן, ה-INP של טרנדים 'איטי' טווח.
למרבה המזל, PSI מספק את שני נתוני השדות עבור דפים שכלולים במשתמש Chrome
דוח חוויית השימוש (CrUX) ונתוני אבחון מפורטים של שיעור Lab. צפייה בשיעור ה-Lab
בדיקת זמן הביצוע של JavaScript ב-Lighthouse הציעה
סקריפט search-result-v2
תופס את ה-thread הראשי יותר זמן מאשר אחר
הסקריפטים שבדף.
![סקירה של מקורות למשימות ארוכות ב-Lighthouse באתר של Trends. אחד המקורות העיקריים למשימות ארוכות הוא סקריפט שמטפל בתוצאות חיפוש ב-PLP של Trends.](https://web.dev/static/case-studies/trendyol-inp/image/fig-2.png?authuser=9&hl=he)
כדי לזהות צווארי בקבוק בעולם האמיתי, השתמשנו בחלונית הביצועים ב-Chrome כלי פיתוח כדי לפתור בעיות בחוויית השימוש ב-PLP ולזהות את המקור בעיה. אמולציה של הביצועים בנייד עם האטה פי 4 של המעבד (CPU) בכלי הפיתוח ל-Chrome גילתה משימה באורך 700-900 אלפיות שנייה ב-thread הראשי. אם העמודה שה-thread נמשך במשימות אחרות במשך יותר מ-50 אלפיות השנייה, יכול להיות שהוא לא יכול להגיב בזמן לקלט של משתמשים, וכתוצאה מכך חוויית המשתמש.
![צילום מסך של סשן הפרופיילינג של הביצועים בכלי הפיתוח ל-Chrome עבור PLP של Trends. המשימה הארוכה שמתוארת פועלת במשך 737.6 אלפיות השנייה, והיא חלק מקריאה חוזרת (callback) של Intersection Observer.](https://web.dev/static/case-studies/trendyol-inp/image/fig-3.png?authuser=9&hl=he)
המשימה הארוכה ביותר נגרמה על ידי קריאה חוזרת (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, שהמשימה הארוכה ביותר פוצלה לסדרה של משימות קטנות יותר, עבודה בעדיפות גבוהה יותר - כגון אינטראקציות של משתמשים ועבודות רינדור נוספות - קיימים מוקדם יותר ממה שהם היו יכולים לעשות.
![צילום מסך של סשן הפרופיילינג של הביצועים בכלי הפיתוח ל-Chrome עבור PLP של Trends. המשימה הארוכה שפעלו בעבר במשך 737.6 אלפיות השנייה מחולקת עכשיו לכמה משימות קטנות יותר.](https://web.dev/static/case-studies/trendyol-inp/image/fig-4.png?authuser=9&hl=he)
שימו לב ש-Trendyol משתמש ב-PuzzleJs framework כדי להטמיע מיקרו-חזית באמצעות React v16.9.0. עם React 18, אותם ביצועים יכולים להיות הושג, אך מכמה סיבות, Trends לא יכול לשדרג בשלב זה בזמן האימון.
תוצאות עסקיות
כדי למדוד את ההשפעה של שיפור ה-INP שהוטמע, הפעלנו בדיקת A/B לראות איך המדדים העסקיים הושפעו. באופן כללי, השינויים ב-PLP הובילו עם שיפור משמעותי, כולל ירידה של 50% במדד INP וירידה של 1% עלייה בשיעורי הקליקים מדף כרטיסי המוצר אל דף פרטי המוצר לכל סשן של משתמש. באיור הבא אפשר לראות את השיפור ב-INP PLP לאורך זמן:
![צילום מסך של מדד ה-INP באחוזון ה-75 של Trends במהלך 6 חודשים. בסוף ששת החודשים האחרונים, מדד ה-INP של טרנדים ירד לכמעט 650 אלפיות השנייה מ-1,400 אלפיות השנייה כמעט.](https://web.dev/static/case-studies/trendyol-inp/image/fig-5.png?authuser=9&hl=he)
סיכום
אופטימיזציה של INP היא תהליך מורכב ואיטרטיבי, אבל אפשר לפשט אותו באמצעות תהליך עבודה ברור. גישה פשוטה לניפוי באגים ושיפור ה-INP של האתר אם אתם אוספים נתוני שדות משלכם. אם הן לא. PSI ו-Lighthouse הן נקודות התחלה טובות. אחרי שמזהים עם בעיות, אפשר להשתמש בכלי הפיתוח כדי לחקור לעומק ולנסות לשחזר בעיות נפוצות.
לבצע מדי פעם תקלה ל-thread הראשי כדי לתת לדפדפן עוד
הזדמנויות לביצוע עבודה דחופה יהפכו את האתר שלך לרספונסיבי יותר,
לכך שהלקוחות שלכם נהנים מחוויית משתמש טובה יותר. ממשקי API חדשים יותר לתזמון
כמו scheduler.yield()
, קל יותר לבצע את המשימה הזו.
תודה מיוחדת לג'רמי וגנר, בארי פולארד וחוסיין ג'רדה מ: Google וצוות ההנדסה של טרנדים על התרומה שלהם למאמצים האלה.