מה זה INP ולמה הוא מחליף את FID?
INP — Interaction to Next Paint — הוא מדד Core Web Vitals שמד את תגובתיות הדף לאינטראקציות משתמש. הוא הפך למדד רשמי במרץ 2024 והחליף את FID (First Input Delay). ההבדל המהותי: FID מדד רק את העיכוב לפני שהדפדפן מתחיל לטפל בקלט, בעוד INP מודד את כל מחזור האינטראקציה — מהקליק ועד לציור המסך המעודכן.
INP לוקח את ה-percentile ה-98 של כל האינטראקציות בסשן ומציג אותו כציון הסשן. זה אומר שגם אם 97% מהקליקים מהירים, אינטראקציה אחת איטית יכולה להוריד את הציון.
יעדי INP
- Good — עד 200 מילישניות
- Needs Improvement — 200–500 מילישניות
- Poor — מעל 500 מילישניות
לשם השוואה: FID היה Good מתחת ל-100ms, אבל FID מדד רק את הקלט הראשון ורק את העיכוב לפני העיבוד. INP הרבה יותר מחמיר ומקיף.
מה INP מודד בדיוק?
כל אינטראקציה מורכבת משלושה שלבים:
- Input Delay — הזמן מהאינטראקציה עד שה-event handler מתחיל לרוץ
- Processing Time — הזמן שלוקח ל-JavaScript לטפל באירוע
- Presentation Delay — הזמן עד שהמסך מצייר מחדש
INP = Input Delay + Processing Time + Presentation Delay. FID מדד רק Input Delay של האינטראקציה הראשונה. הרחבה זו הופכת INP לייצוגי הרבה יותר של חוויית המשתמש האמיתית.
סיבות נפוצות לINP גרוע
Long Tasks ב-Main Thread
המסוכן ביותר: JavaScript שרץ יותר מ-50ms על ה-main thread. בזמן שהקוד רץ, הדפדפן לא יכול לטפל בקלט — כל הקליקים "נעצרים". פתרון: חלוקת Long Tasks ל-smaller chunks עם scheduler.yield() או setTimeout().
Heavy Event Listeners
Event listeners שמבצעים חישובים כבדים (DOM manipulation מסיבית, חישובי layout) מגדילים את Processing Time. פתרון: העבר לוגיקה כבדה ל-Web Workers, השתמש ב-requestAnimationFrame לשינויי עיצוב.
Forced Layout/Reflow
קריאת מאפייני גיאומטריה (offsetWidth, getBoundingClientRect) מייד אחרי שינוי DOM גורמת ל-forced reflow — גוגל קורא לזה "layout thrashing". פתרון: batch DOM reads לפני DOM writes.
Third-Party Scripts
ספריות Analytics, Chat widgets, Ads — כולם רצים על ה-main thread ומשפיעים על INP. השתמש ב-Partytown לבידוד third-party scripts ל-Web Worker.
כיצד לאבחן בעיות INP?
כמה כלים:
- Chrome DevTools → Performance: הקלט "Record", בצע פעולות, בדוק Long Tasks (מסומנות באדום)
- PageSpeed Insights: מציג INP לדף ספציפי עם נתוני שטח (Real User Data)
- Google Search Console: דוח Core Web Vitals מציג דפים עם INP Poor/Needs Improvement
- web-vitals.js library: מדוד INP בזמן אמת בפרודקשן ושלח לAnalytics
תיקון INP — סדר עדיפויות
הגישה המומלצת:
- זהה את האינטראקציות הכי איטיות עם DevTools Performance profiler
- שבור Long Tasks (מעל 50ms) ל-יחידות קטנות עם scheduler.yield()
- הזז חישובים כבדים ל-Web Workers
- עבור לאחר render — defer עדכוני UI שאינם דחופים עם startTransition() ב-React
- בדוק third-party scripts — כבה אחד-אחד ומדוד אם INP משתפר
INP ו-SEO — כמה זה משפיע על הדירוג?
Core Web Vitals (LCP, INP, CLS) הם גורם דירוג רשמי ב-Google Page Experience signal. אין עדיין מחקר מדויק על משקל INP ביחס ל-LCP, אבל Google ציינה שכל שלושת המדדים נבחנים ביחד כ-"Core Web Vitals threshold". אתר שכולם "Good" מקבל boost; אתר עם אחד "Poor" מפסיד אותו. עבור SEO טכני מקצועי, ה-INP score שלך צריך להיות מתחת ל-200ms.