INP: איך משפרים את התגובתיות של האתר ללחיצות

INP (Interaction to Next Paint) הוא המדד של גוגל לתגובתיות של אתר: כמה זמן עובר מהרגע שהגולש לוחץ, מקיש או מקליד ועד שהמסך מציג תגובה. לפי web.dev, INP של 200 מילישניות או פחות נחשב טוב, ומעל 500 מילישניות — גרוע. INP החליף את המדד הקודם, FID, כחלק מ-Core Web Vitals ב-12 במרץ 2024. ההבדל המהותי: FID מדד רק את העיכוב של האינטראקציה הראשונה, ו-INP מסתכל על כל האינטראקציות לאורך כל הביקור.

מה INP מודד בדיוק

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

כל אינטראקציה מתחלקת לשלושה שלבים:

כמה זה בעיה בפועל

לפי Web Almanac 2025, 97% מהאתרים מקבלים INP טוב במחשב — אבל רק 77% במובייל. פער של 20 נקודות אחוז, הגדול מבין כל המדדים. הסיבה פשוטה: מעבד של טלפון בינוני חלש בהרבה ממחשב, ואותו קוד רץ עליו לאט יותר. אתר שמרגיש מהיר במחשב של המפתח יכול להרגיש תקוע בטלפון של הלקוח.

הבעיה המרכזית: משימות ארוכות

הדפדפן מריץ JavaScript, מחשב עיצוב ומצייר את המסך כולם על אותו "תהליכון ראשי", ולפי המדריך של web.dev למשימות ארוכות, התהליכון הזה מבצע משימה אחת בכל רגע. משימה שנמשכת יותר מ-50 מילישניות נחשבת משימה ארוכה, ובזמן שהיא רצה הדפדפן לא יכול להגיב ללחיצה. כל אופטימיזציה של INP מסתכמת בעצם בשאלה אחת: איך מקצרים או מפצלים את המשימות שרצות כשהגולש מנסה ללחוץ.

מה משפר INP

1. פחות קוד שרץ ברקע

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

2. לפצל משימות כבדות

כשהקוד שמגיב ללחיצה חייב לעשות הרבה עבודה — סינון רשימה ארוכה, חישוב — מפצלים אותה. web.dev ממליצה "לוותר על התור" (Yield) בין חלקים, כך שהדפדפן יכול לעדכן את המסך ולטפל בלחיצות באמצע. הדרך המועדפת שלה היא scheduler.yield(), עם גיבוי של setTimeout בדפדפנים שלא תומכים בו:

async function processItems(items) {
  for (const item of items) {
    handle(item);
    await scheduler.yield(); // let the browser respond
  }
}

בפועל לא מוותרים אחרי כל פריט, כי לזה יש מחיר — web.dev מציעה לעבוד בקבוצות ולוותר רק כשעברו כ-50 מילישניות.

3. קודם להראות תגובה, אחר כך לעבוד

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

4. עמוד קטן יותר

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

5. לא להשתמש ב-isInputPending

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

איך מוצאים את האינטראקציה האיטית

1. נתוני שטח: דוח Core Web Vitals ב-Search Console ונתוני גולשים אמיתיים מראים אם יש בעיה ובאילו עמודים.
2. בדפדפן: בכלי המפתחים, בלשונית Performance, מפעילים האטת מעבד (כדי לדמות טלפון), מקליטים ולוחצים על הרכיבים החשודים — תפריט, מסנן, כפתור הוספה לעגלה.
3. מחפשים בהקלטה משימות ארוכות סביב הלחיצה ובודקים מאיזה קובץ הן מגיעות.

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

שאלות נפוצות

מה ההבדל בין INP ל-FID?

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

האתר שלי מקבל ציון ביצועים גבוה, ובכל זאת INP גרוע. איך?

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

שיפור INP דורש לרוב עבודה בקוד ולא רק בהגדרות, וזה חלק מעבודת שיפור מהירות אתר שלי. אם Search Console מסמן לכם בעיית INP, שלחו לי את הכתובת.