מהירות התגובה לאינטראקציה באתר (INP)

Jeremy Wagner

Barry Pollard

פורסם: 6 במאי 2022, עדכון אחרון: 9 בספטמבר 2025

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

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

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

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

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

במדריך הזה מוסבר איך מדד INP פועל, איך מודדים אותו ואיפה אפשר למצוא מקורות מידע שיעזרו לכם לשפר אותו.

מה זה INP?

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

אינטראקציה היא קבוצה של רכיבי handler של אירועים שמופעלים במהלך אותה תנועת משתמש לוגית. לדוגמה, אינטראקציות של 'הקשה' במכשיר עם מסך מגע כוללות כמה אירועים, כמו pointerup, pointerdown ו-click. האינטראקציה יכולה להיות מבוססת על JavaScript,‏ CSS, אמצעי בקרה מובנים בדפדפן (כמו רכיבי טופס) או שילוב שלהם.

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

מהו ציון INP טוב?

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

כדי לוודא שחוויית המשתמש באתר שלכם רספונסיבית, מומלץ למדוד את האחוזון ה-75 של טעינות הדפים שנרשמו בשטח, בפילוח לפי מכשירים ניידים ומחשבים:

• ערך INP של 200 מילישניות או פחות מצביע על רספונסיביות טובה של הדף.
• ערך INP מעל 200 אלפיות השנייה ומתחת ל-500 אלפיות השנייה או שווה לו, מצביע על כך שיש לשפר את הרספונסיביות של הדף.
• ערך INP מעל 500 מילישניות מצביע על רספונסיביות נמוכה של הדף.

מה כוללת אינטראקציה?

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

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

• לחיצה עם העכבר.
• הקשה על מכשיר עם מסך מגע.
• לחיצה על מקש במקלדת פיזית או במקלדת וירטואלית.

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

אינטראקציות יכולות לכלול כמה אירועים. לדוגמה, הקשה על מקש כוללת את האירועים keydown, keypress ו-keyup. אירועים מסוג 'הקשה על אינטראקציות' מכילים אירועים מסוג pointerup ו-pointerdown. האירוע עם משך הזמן הארוך ביותר במהלך האינטראקציה הוא זה שמשפיע על זמן האחזור הכולל של האינטראקציה.

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

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

מה ההבדל בין INP לבין השהיה לאחר קלט ראשוני (FID)?

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

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

מה קורה אם לא מדווח ערך INP?

יכול להיות שדף לא יחזיר ערך INP. יכולות להיות לכך כמה סיבות, כולל:

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

איך מודדים INP

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

בשדה

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

אם האתר שלכם עומד בדרישות להכללה בדוח חוויית המשתמש ב-Chrome‏ (CrUX), תוכלו לקבל במהירות נתוני שטח לגבי INP דרך CrUX בכלי PageSpeed Insights (וגם לגבי מדדים בסיסיים אחרים של חוויית המשתמש). לפחות, תוכלו לקבל תמונה ברמת המקור של מדד ה-INP באתר שלכם, אבל במקרים מסוימים תוכלו גם לקבל נתונים ברמת כתובת ה-URL.

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

במעבדה

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

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

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

מדידת INP ב-JavaScript

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

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

ההבדלים בין המדד לבין ה-API

• כברירת מחדל, לא מדווחים על ערכים של event מתחת ל-104 אלפיות השנייה באמצעות כלי מעקב אחר ביצועים. אפשר לשנות את ברירת המחדל הזו כשרושמים כלי למעקב אחר ביצועים באמצעות הפרמטר durationThreshold, אבל גם כאן יש ערך מינימלי של 16 אלפיות השנייה. לכן מומלץ לעקוב גם אחרי הרשומה first-input, שהיא גם רשומה של תזמון אירוע, אבל מובטח שאפשר יהיה לראות אותה גם אם משך הזמן שלה קצר מ-durationThreshold. כך אפשר לוודא שבדפים עם אינטראקציות תמיד ידווח ערך INP כלשהו.
• מבחינה טכנית, כדי לחשב אחוזונים בצורה מדויקת צריך לשמור את כל הדגימות בזיכרון, וזה עלול להיות יקר. אבל אפשר להעריך אחוזונים, במיוחד אחוזונים גבוהים מאוד כמו p98, פשוט על ידי שמירת רשימה קטנה של האינטראקציות הגרועות ביותר. 10 היא בחירה נפוצה.
• אם דף משוחזר ממטמון לדף הקודם/הבא, ערך ה-INP שלו צריך להתאפס לאפס, כי המשתמשים חווים את זה כביקור נפרד בדף.
• ה-API לא מדווח על רשומות event של אינטראקציות שמתרחשות בתוך iframe, אבל המדד כן מדווח עליהן כי הן חלק מחוויית המשתמש בדף. ההבדל הזה יכול להופיע כהבדל בין CrUX לבין RUM. כדי למדוד את מדד INP בצורה נכונה, צריך להתייחס אליהם. מסגרות משנה יכולות להשתמש ב-API כדי לדווח על event-timing הרשומות שלהן למסגרת האב.

בנוסף לחריגים האלה, יש מורכבות נוספת במדד INP בגלל שהוא מודד את כל משך החיים של הדף:

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

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

במקום לזכור את כל המקרים האלה ולהתמודד איתם בעצמכם, מפתחים יכולים להשתמש בספריית ה-JavaScript‏ web-vitals כדי למדוד את מדד ה-INP, שמביא בחשבון את כל מה שצוין למעלה, למעט המקרה של iframe:

import {onINP} from 'web-vitals';

// Measure and log INP in all situations
// where it needs to be reported.
onINP(console.log);

איך לשפר את מדד INP

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

יומן שינויים

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

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

אם יש לכם משוב על המדדים האלה, אתם יכולים לפרסם אותו בקבוצת Google web-vitals-feedback.

בוחנים את הידע