אופטימיזציה של מודעות INP עזרה ל-redBus להגדיל את המכירות בכ-7%
האינטרנט והיכולות שלו מתפתחים במהירות. עכשיו אפשר ליצור חוויות עשירות ומלאות תכונות באינטרנט, שיכולות להשיג הרבה מהיכולות של אפליקציות מקוריות.
JavaScript הוא גורם מרכזי ליצירת אינטראקטיביות באינטרנט, אבל אם לא משתמשים בו בזהירות, האינטראקציות עשויות להיראות איטיות ולגרום למשתמשים לחשוב שהאתר לא מגיב או שהוא פגום לגמרי. למרבה המזל, המדד מהירות התגובה לאינטראקציה באתר (INP) נוצר כדי לטפל בבעיה הספציפית הזו בחוויית המשתמש.
מדד INP מודד את כל האינטראקציות עם דף במהלך מחזור החיים שלו, ומדווח על ערך יחיד שמייצג את מהירות התגובה של האתר לקלט של משתמשים. במילים פשוטות, אם מדד ה-INP של דף מסוים הוא בסף הטוב או נמוך ממנו, אפשר לומר שכל האינטראקציות עם הדף מהירות באופן מהימן.
redBus הוא אתר להזמנת כרטיסים לאוטובוסים שנמצא בהודו. באתר הזה השקיעו מאמצים רבים כדי לשפר את מדד INP של האתר, גם בתקופה שבה הוא עדיין נחשב למדד ניסיוני. בעקבות המאמצים שלהם, הם הצליחו להגדיל את המכירות ב-7%, שוב מוכיחים את הקשר בין ביצועי האתר לבין בריאות העסק. ריכזנו כאן את הפעולות שביצעה redBus כדי לשפר את מדד INP של האתר שלה.
היעדים המובילים
כש-redBus יצאה לאופטימיזציה של ה-INP באתר שלה, היו לה שלושה יעדים בראש:
- התמקדות בזמן האחזור של האינטראקציה, ללא קשר למהירות הרשת וליכולות המכשיר, תעזור לכם לספק למשתמשים חוויית שימוש טובה יותר.
- מבצעים אופטימיזציה של האתר כדי שהאינטראקציות יהיו מהירות ככל האפשר.
- מוודאים שהתשובות מה-API הן קצרות ככל האפשר כדי להבטיח העברת נתונים מהירה לממשק הקצה.
התהליך
צוות redBus סיווג את זמני האחזור של האינטראקציות בשתי דרכים:
- זמן האחזור של האינטראקציה שנגרם כתוצאה מחסימת JavaScript בצד הלקוח. כשאינטראקציות כוללות שימוש מוגזם ב-JavaScript שחוסם את השרשור הראשי, העיבוד מושהה, והדבר משפיע על INP של הדף.
- זמן אחזור ברשת שנגרם על ידי קריאות ל-API. פעילות הרשת היא לא דבר ש-INP מודד, אבל אינטראקציה שמבוססת על קריאה ל-API מרוחק עשויה להיראות איטית ברשתות איטיות יותר, או אם הבקשות יוצרות תגובות גדולות.
בתחילה, ב-redBus היו בטוחים שה-INP של האתר שלהם יהיה טוב, אבל הנתונים של מעקב אחר משתמשים אמיתיים (RUM) לגבי המדד הזה ב-95% העליונים סיפרו סיפור אחר.
איך redBus מדדה את INP
ב-redBus השתמשו בספריית JavaScript web-vitals שפותחה על ידי Google כדי לעקוב לא רק אחרי אירועי INP, אלא אחרי כל המדדים החשובים של חוויית המשתמש בכל הדפים באתר. בנוסף לספריית JavaScript web-vitals, צוות redBus השתמש ב-ELK כדי לנתח את נתוני ה-INP שנאספו בממשק הקצה.
עם זאת, האופן שבו אתם עוקבים אחרי ה-INP של האתר בשטח עשוי להיות שונה מאוד מהאופן שבו redBus ניגשה לבעיה. לפני שמתחילים לבצע אופטימיזציה של האינטראקציות, מומלץ מאוד לקרוא את המאמר איך למצוא אינטראקציות איטיות בשטח כדי ללמוד איך לעקוב בצורה הטובה ביותר אחרי אינטראקציות ראשוניות באתרים, ואז איך לשחזר אותן במעבדה.
אחרי ש-redBus הטמיעה מערכת למעקב אחר אינטראקציות ראשוניות עם משתמשים, היא הצליחה לנתח את הנתונים כדי להבין טוב יותר איפה הייתה אינטראקציה איטית.
תרחישים לדוגמה
כשמשתמשים מחפשים מחירי כרטיסים באתר redBus, הם יכולים לשנות את התאריך בדף החיפוש כדי לסנן את מחירי הכרטיסים שנבחרו ליעד הרצוי. האינטראקציה לשינוי התאריך בדף הזה הייתה איטית וגרמה ל-INP נמוך.
בנוסף, כשמשתמש גולל בין מחירי הכרטיסים, מחירי כרטיסים נוספים נטענים ב-lazy-load מה-API. למרות שהגלילה עצמה לא נכללת במדידה של INP, רכיב ה-listener של האירוע scroll מתזמן בעצמו הרבה עבודה שצריכה לפעול בשרשור הראשי. העבודה הזו גרמה להתנגשות בשרשור הראשי, שהאריכה את זמן האחזור של האינטראקציה, וכתוצאה מכך ל-INP נמוך בדף החיפוש.
איך redBus ביצעה אופטימיזציה של INP בדף החיפוש
כדי לשפר את INP בדף החיפוש, צוות redBus ביצע כמה פעולות אופטימיזציה:
- הוספה של זמן השהיה לטיפול באירוע
scrollכדי לצמצם את מספר הפעמים שבהן תיגרם הפעלה חוזרת של פונקציית ה-call back של האירוע בתקופה נתונה. הפחתת התדירות שבה פונקציית ה-callback של האירועscrollמופעלת אפשרה לשרשור הראשי להגיב מהר יותר לאינטראקציות של המשתמשים בדף החיפוש. - העבודה על העיבוד שהתקבלה הוקצתה לעדיפות גבוהה באמצעות קריאה חוזרת (callback) של
requestAnimationFrame. הערךrequestAnimationFrameמורה לדפדפן שהעבודה בפונקציית ההתקשרות החוזרת חייבת להסתיים לפני המסגרת הבאה.
בנוסף, ביצענו את האופטימיזציות הבאות בדף תוצאות החיפוש:
- כדי לשפר את חוויית המשתמש ואת הביצועים החזותיים, המערכת עוררה טעינה איטית מוקדם יותר, והחזירה קבוצות חדשות של תוצאות בכרטיס השני מתוך השלישי בדף תוצאות החיפוש.
- במהלך הטעינה האיטית, נשלחו פחות בקשות לרשת כדי לאחזר תוצאות. בעקבות הפחתת מספר האחזורים מ-30 לתוצאות ל-10 תוצאות, נצפתה ירידה בטווח ה-INP מ-870 עד 900 ל-350 עד 370.
השינויים האלה שיפרו באופן משמעותי את INP של דף החיפוש, אבל הבעיה עדיין הייתה קיימת: האירוע change בשדות הקלט של דף החיפוש יביא לקריאה לפונקציית reducer יקרה כדי לעדכן את ממשק המשתמש. כתוצאה מכך, התבצעה עיבוד מחדש מיותר של ממשק המשתמש, שהשפיע על מדד ה-INP של הדף.
כדי לבצע אופטימיזציה של האינטראקציה הזו, צוות redBus ניהל את המצב של רכיבי הקלט באופן מקומי וסינכרון אותו עם המאגר של Redux רק כשהאירוע blur של הקלט הופעל. השינוי הזה צמצם את מספר הרינדורים מחדש והפסיק את הרינדור מחדש הלא רצוי של ממשק המשתמש, על ידי קריאה ל-reducer בתדירות נמוכה יותר.
בעקבות השינוי הזה, מדד ה-INP של הדף השתפר ב-72%, וכתוצאה מכך חוויית המשתמש מהירה וחלקה יותר, ויש סיכוי גבוה יותר שהמשתמשים יתעניינו בה.
ההשפעה על העסק
הקשר בין בריאות העסק לביצועים של הדף ידוע. INP הוא מדד חדש יחסית בהשוואה למדדים אחרים של Core Web Vitals, אבל ב-redBus ראו שיפור בתוצאות העסקיות כשהתמקדנו בשיפור המדד החשוב הזה של ביצועים שמתמקדים במשתמש. התוצאה הייתה עלייה של 7% במכירות הכוללות.
בקיצור, ה-INP עזר לתאר את בעיות הביצועים בסביבת זמן הריצה באתר של redBus. לאחר שהבינו שיש שיפורים שאפשר לבצע, הצוות של redBus הצליח לבחון את הבעיה, לשחזר אותה ולהשתמש במידע החיוני הזה כדי לבצע אופטימיזציות שתרמו ל-redBus ולעסק שלה.