איך חברת redBus שיפרה את האינטראקציה של האתר שלהם עם INP (INP) והגדילה את המכירות ב-7%

האופטימיזציה של INP סייעה ל-redBus להגדיל את המכירות ב-7%

Amit Kumar

Saurabh Rajpal

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

JavaScript הוא אמצעי עיקרי לאינטראקטיביות באינטרנט, אך אם לא משתמשים בו בזהירות, האינטראקציות שלו עלולות להיראות איטיות ולגרום למשתמשים לחשוב שהאתר לא מגיב או מנותק לגמרי. למרבה המזל, המדד Interaction to Next Paint (INP) נוצר כדי לטפל בבעיה הספציפית הזו בחוויית המשתמש.

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

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

יעדים מובילים

כאשר חברת RedBus רצתה לבצע אופטימיזציה ל-INP של האתר, היו לה שלושה יעדים:

1. כדי לספק למשתמשים חוויית משתמש טובה יותר, אפשר להתמקד בזמן האחזור של האינטראקציה בלי קשר למהירות הרשת וליכולות המכשיר.
2. לבצע אופטימיזציה של האתר כדי שהאינטראקציות יהיו כמה שיותר מהירות.
3. ודאו שהתגובות מה-API היו קלות ככל האפשר כדי להבטיח העברת נתונים מהירה לממשק הקצה.

המסע

זמן האחזור של אינטראקציה בסיווג RedBus בשתי דרכים:

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

ב-redBus היו בהתחלה די בטוחים שה-INP באתר שלהם יהיה טוב, אבל הנתונים של Real User Monitoring (RUM) עבור המדד הזה באחוזון ה-95 הציגו סיפור אחר.

איך RedBus מדד INP

RedBus הסתמכה על ספריית web-vitals של JavaScript שפותחה על ידי Google כדי לעקוב לא רק אחרי INP, אלא גם אחרי כל המדדים החשובים של חוויית המשתמש בכל הדפים באתר. בנוסף לספריית JavaScript של web-vitals, ב-redBus נעשה שימוש ב-ELK כדי לנתח נתוני INP שנאספו בממשק הקצה.

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

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

תרחישים לדוגמה

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

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

איך חברת RedBus ביצעה אופטימיזציה של INP לדף החיפוש

כדי לשפר את ה-INP של דף החיפוש, RedBus ביצע מספר אופטימיזציות:

• הגורם המטפל באירועים של scroll בוצעה יציאה מדף הכניסה כדי לצמצם את מספר הפעמים שהקריאה החוזרת של האירוע תופעל בתקופה נתונה. הורדה של התדירות שבה בוצעה קריאה חוזרת של האירוע scroll תאפשר ל-thread הראשי להגיב מהר יותר לאינטראקציות של משתמשים בדף החיפוש.
• עבודת הרינדור שהתקבלה קיבלה עדיפות על ידי שימוש בקריאה חוזרת (callback) של requestAnimationFrame. requestAnimationFrame מורה לדפדפן שהעבודה בקריאה החוזרת צריכה להתבצע לפני הפריים הבא.

בנוסף, האופטימיזציות הנוספות הבאות בוצעו בדף תוצאות החיפוש:

• קבוצות חדשות של תוצאות אוחזרו בכרטיס השני לפני האחרון בדף תוצאות החיפוש, כדי לשפר את חוויית המשתמש ואת הביצועים החזותיים על ידי הפעלה של טעינה מושהית מוקדם יותר.
• פחות תוצאות אוחזרו בכל שיחת רשת במהלך טעינה מושהית. על ידי צמצום של אחזורים מ-30 ל-10 תוצאות, נצפתה ירידה בטווחי ה-INP מ-870 ל-900 מ-350 ל-370.

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

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

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

ההשפעה על העסק

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

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