תוכן העניינים
העמוד כבר מוצג. הכותרת במקום, התמונה נטענה, ואפשר לקרוא את התוכן. לוחצים על התפריט — ושום דבר לא קורה. לוחצים שוב, ואז הוא נפתח ונסגר כמעט באותו רגע.
מבחינת המשתמש, האתר נתקע. מבחינת בדיקת טעינה רגילה, ייתכן שהכול נראה סביר.
הפער הזה נמצא במרכז מדד INP, קיצור של Interaction to Next Paint. המדד בוחן את התגובה לאינטראקציות כמו לחיצות, נגיעות במסך והקשות במקלדת במהלך הביקור בעמוד. הוא מתמקד באינטראקציות האיטיות, תוך התחשבות בחריגים, ולא רק בפעולה הראשונה אחרי הכניסה לאתר.
כדי לשפר אותו, צריך לחקור את מה שקרה סביב הלחיצה: במה הדפדפן היה עסוק, איזו עבודה הופעלה בעקבותיה וכמה זמן עבר עד שיכול היה להציג את הפריים הבא.
הלחיצה התקבלה, אבל הדפדפן עדיין עסוק
חלק גדול מעבודת הדפדפן מתבצע בתהליכון הראשי, ה־Main Thread. זה המקום שבו רץ רוב קוד ה־JavaScript של העמוד ומתבצעת גם עבודה הנדרשת להצגת הממשק.
התהליכון הזה מטפל במשימה אחת בכל רגע. אם הוא עסוק במשימה ממושכת כשהמשתמש לוחץ, הטיפול בלחיצה עשוי להמתין.
מכאן מגיעה תופעה מבלבלת: הכפתור עצמו יכול להיות פשוט, ובכל זאת להגיב באיחור. העבודה שמעכבת אותו עשויה להשתייך לרכיב אחר בעמוד — למשל גלריה, מנגנון חיפוש או סקריפט שפועל ברקע.
גם אתר שנטען במהירות יכול להגיע למצב הזה בהמשך הביקור. מספיק שפעולה מסוימת תפעיל חישוב כבד או עדכון נרחב של הממשק.
לכן, השאלה הראשונה בחקירה היא: איזו פעולה הרגישה איטית, ובאילו תנאים היא התבצעה? „האתר איטי במובייל” הוא תיאור רחב מדי כדי לבחור תיקון.
מפרקים את העיכוב לשלושה שלבים
משך האינטראקציה מורכב משלושה חלקים. ההבחנה ביניהם חשובה משום שכל אחד עשוי לדרוש טיפול אחר.
| שלב | מה מתרחש | דוגמה אפשרית |
|---|---|---|
| השהיית קלט — Input Delay | הפעולה ממתינה עד שהדפדפן מתחיל לטפל באירועים שלה | סקריפט אחר מעסיק את התהליכון הראשי |
| זמן עיבוד — Processing Duration | הקוד שמטפל באינטראקציה רץ | לחיצה על מסנן מפעילה חישוב ועדכון של רשימת מוצרים |
| השהיית הצגה — Presentation Delay | הדפדפן משלים את העבודה עד להצגת הפריים הבא | חישובי עיצוב ופריסה לאחר שינוי הממשק |
בדוגמה להמחשה בלבד, לחיצה יכולה להמתין 180 מילישניות, להפעיל עיבוד שנמשך 240 מילישניות ולדרוש עוד 110 מילישניות עד להצגה. בסך הכול עברו 530 מילישניות.
אם מטפלים רק בקוד שמופעל בלחיצה, חלק ניכר מהעיכוב עשוי להישאר. ואם מקור הבעיה הוא עדכון כבד של הפריסה, דחיית סקריפט לא קשור לא בהכרח תפתור אותה.
ספי ההערכה של INP הם עד 200 מילישניות לתגובה טובה, מעל 200 ועד 500 לתגובה שדורשת שיפור, ומעל 500 לתגובה חלשה. בהערכת נתוני משתמשים מתייחסים לאחוזון ה־75 של ערכי המדד, בנפרד למובייל ולדסקטופ. לחיצה איטית אחת בבדיקה אינה מספיקה כדי לקבוע את מצב האתר כולו.
תגובה ללחיצה והשלמת הפעולה הן שתי בדיקות שונות
INP אינו מודד בהכרח את כל הזמן עד להשלמת פעולה מול השרת.
למשל, לאחר שליחת טופס אפשר להציג מיד שהבקשה בטיפול, בזמן שהשרת עדיין מעבד אותה. זו תגובה שימושית: המשתמש יודע שהלחיצה התקבלה.
אבל חיווי מהיר אינו פותר המתנה ארוכה לתוצאה. צריך לבדוק גם שהפעולה מסתיימת בזמן סביר ושמוצגת תשובה אמינה. הודעת הצלחה צריכה להופיע רק לאחר שהפעולה אכן הצליחה.
החשודים נמצאים גם מחוץ לכפתור
כאשר מתגלה אינטראקציה איטית, יש כמה כיווני חקירה. הם אינם רשימת רכיבים שצריך להסיר אוטומטית.
עבודה ארוכה ב־JavaScript. חישוב, עיבוד נתונים או סדרת פעולות שרצה ברצף עלולים לעכב את הממשק. לפעמים אפשר לפצל את העבודה ולאפשר לדפדפן לטפל בתגובה למשתמש בין החלקים.
יותר מדי עבודה בעקבות פעולה קטנה. בחירה במסנן אחד עשויה לגרום לעדכון של אזורים רבים בעמוד. כדאי לבדוק איזה חלק באמת השתנה ואיזו עבודה אפשר לצמצם.
סקריפטים ושירותים חיצוניים. רכיבי צ'אט, פרסום, מדידה והתאמה אישית יכולים להוסיף עבודה לדפדפן. בהנחיות של Wix לשיפור מדדי חוויית המשתמש מומלץ לבחון קוד צד שלישי ולצמצם אפליקציות ווידג'טים שאינם חיוניים. את ההחלטה בפועל כדאי לבסס על מדידה ועל התפקיד העסקי של כל רכיב.
ממשק שמחייב חישובי תצוגה רבים. עמוד עם כמות גדולה של רכיבים ועדכוני פריסה מורכבים עשוי לדרוש יותר עבודה לפני הצגת השינוי. כאן הפתרון יכול לערב גם את מבנה הרכיב ואת העיצוב שלו.
העומס הזה אינו נמדד רק במספר התוספים. תוסף יחיד יכול להפעיל עבודה משמעותית, בעוד שכמה תוספים אחרים כמעט אינם משפיעים על האינטראקציה שנבדקת.
גם מטמון אינו פתרון אוטומטי: הוא עשוי לעזור בהגשת העמוד והמשאבים, אבל העבודה שהדפדפן מבצע בעקבות לחיצה עדיין דורשת אבחון.
בודקים את האירוע במעבדה ומשווים לחיים עצמם
נתוני שטח ובדיקות מעבדה עונים על שאלות שונות.
נתוני שטח מתארים את החוויה שנמדדה אצל משתמשים בפועל, עם מכשירים והרגלי שימוש שונים. ב־PageSpeed Insights חשוב לבדוק אם הנתון מתייחס לכתובת המסוימת או לרמת האתר. נתון כללי אינו מוכיח שכל התבניות מתנהגות באותה צורה.
היעדר נתון INP יכול לנבוע ממחסור בדגימות מתאימות. הוא אינו אישור לכך שהעמוד מגיב היטב.
בדיקת מעבדה מאפשרת לשחזר פעולה ולחקור אותה. פותחים את כלי הביצועים בדפדפן, מקליטים את הפעולה ובודקים היכן התבזבז הזמן. רצוי לבחור מסלולים שאנשים באמת מבצעים: פתיחת תפריט, חיפוש, סינון מוצרים, בחירת אפשרות או מילוי טופס.
כדאי לנסות את הפעולה גם בזמן הטעינה וגם לאחר שהעמוד התייצב. יש הבדל בין תפריט שמגיב באיחור רק בשניות הראשונות לבין חיפוש שנתקע בכל הקלדה.
מחשב פיתוח חזק עשוי להסתיר חלק מהבעיה. בדיקה במכשיר נייד מייצג, לצד הדמיית מגבלות עיבוד במעבדה, יכולה לסייע בשחזור. הדמיה עדיין אינה תחליף מלא לשימוש במכשיר אמיתי.
אם הנתונים הכלליים אינם מגלים איזו פעולה אחראית לעיכוב, מדידת משתמשים ייעודית יכולה להוסיף הקשר: סוג האינטראקציה, הרכיב המעורב והשלב שבו נוצר העיכוב.
העובדה שהקוד משפיע על תגובתיות אינה אומרת שיש גם בעיית אינדוקס. אלה בדיקות נפרדות, כפי שמוסבר במאמר על בעיות רינדור ואינדוקס באתרי JavaScript.
מה מעבירים לפיתוח, לעיצוב ולניהול האתר?
ממצא טוב מתאר אירוע שאפשר לשחזר. למשל, דיווח לבדיקה יכול להיראות כך:
בעמוד הקטגוריה, לחיצה על מסנן במובייל מגיבה באיחור. השחזור כולל כניסה לעמוד, המתנה לטעינה ובחירת המסנן. יש לצרף את תנאי הבדיקה והקלטת הביצועים, ולבדוק איזה שלב מעכב את הצגת התגובה.
מכאן מחלקים את העבודה לפי הממצא.
צוות הפיתוח בודק את המשימות הארוכות, את הקוד שמטפל באירוע ואת עבודת הרינדור. הוא יכול לצמצם עיבוד, לפצל משימות ולתזמן עבודה שאינה נחוצה לתגובה המיידית.
צוות העיצוב וחוויית המשתמש מגדיר מה אמור להופיע מיד לאחר הפעולה: פתיחת רכיב, סימון בחירה או חיווי המתנה. ההחלטה הזאת עוזרת לפיתוח לתעדף את העבודה הנכונה.
ניהול התוכן והשיווק בוחנים אילו הטמעות ורכיבים דרושים בכל תבנית. אפשר לבדוק אם שירות מסוים נחוץ בכל האתר או רק בעמודים שבהם משתמשים בו.
אחראי ה־SEO או הביצועים מתעד את המצב לפני השינוי, בודק שהתקלה השתפרה ועוקב אחרי נתוני השטח. בגלל חלון המדידה המתגלגל, תיקון לא בהכרח ישנה מיד את הערך שמופיע בדוח.
בסיום חוזרים לאותה פעולה ובאותם תנאים ככל האפשר. בודקים שהתגובה מהירה יותר, שהפונקציונליות נשמרה ושלא נוצרה המתנה חדשה בהמשך.
המבחן המעשי הוא הרגע שבו המשתמש לוחץ פעם אחת ומקבל חיווי מתאים בזמן. מדידה טובה מאפשרת לאתר מה מנע את הרגע הזה — ולתקן את העבודה שגרמה לעיכוב.
