INP — כמה מהר הדף שלכם מגיב ללחיצות?
INP מודד כמה מהר הדף מגיב ללחיצות, הקלדה ונגיעות. הוא החליף מדד ישן ב-2024 ומחמיר יותר. מטרה: מתחת ל-200 אלפיות השנייה.
מה זה INP ולמה זה משנה?
INP הוא Interaction to Next Paint — מדד שמחשב כמה זמן עובר מהרגע שמשתמש לחץ על משהו עד לרגע שהדף מגיב ומציג את השינוי על המסך.
דמיינו שלחצתם על "הוסף לסל קניות" ולא קרה כלום במשך חצי שנייה. המחשבה הראשונה — "האם זה עבד?" — ולחצתם שוב. זה בדיוק מה ש-INP גרוע גורם: תחושה שהאתר "תקוע" או "לא מגיב".
גוגל החליטה ב-2024 שמדד INP הוא חלק רשמי מ-Core Web Vitals, והחליף מדד קודם שנחשב קל מדי. הסף: עד 200 אלפיות שנייה — מצוין. 200-500 — בינוני. מעל 500 — גרוע.
מה גורם ל-INP איטי?
הסיבה העיקרית ל-INP גרוע היא JavaScript כבד שתופס את ה-Thread הראשי (Main Thread) — ה"מוח" של הדפדפן שמטפל בכל הלחיצות, הקלדות ועדכוני המסך.
כשה-Thread הראשי עסוק בחישוב כבד — למשל בטעינת קוד או ניתוח נתונים או בסריקת רכיב מסובך — הוא לא יכול לטפל בלחיצות המשתמש. הלחיצה "מחכה בתור" עד שה-Thread יתפנה.
גורמים נפוצים: סקריפטים של צד שלישי כמו Google Tag Manager, צ'אטים כמו Intercom, ווידג'טים של רשתות חברתיות — כולם מוסיפים קוד שרץ ב-Thread הראשי ועלול לעכב תגובה.
גורם נוסף: דפים עם מבנה HTML גדול מאוד (עשרות אלפי אלמנטים) — כל לחיצה גורמת לדפדפן לחשב מחדש את כל הפריסה, מה שלוקח זמן.
מדידת INP — איך יודעים אם יש בעיה?
הדרך הפשוטה ביותר: Google Search Console — תחת Core Web Vitals תוכלו לראות אם יש דפים עם INP גרוע, לפי נתוני משתמשים אמיתיים.
כלי שני: PageSpeed Insights — מציג את ה-INP Field Data (נתוני שטח) לצד ה-Lab Data (בדיקת מעבדה). תשימו לב שה-INP הוא Field Data — מה שחשוב לגוגל.
לאיתור הבעיה הספציפית: ב-Chrome DevTools (F12) בלשונית Performance תוכלו להקליט את הדף, ללחוץ על כפתורים שונים, ולראות בדיוק מה קורה אחרי הלחיצה — איזה קוד רץ ועד כמה.
שיפור INP — דחיית סקריפטים
הצעד הפשוט ביותר לשיפור INP: לוודא שסקריפטים של צד שלישי לא נטענים לפני שהדף מוכן. כלומר, סקריפטים כמו ניתוח נתונים, צ'אטים ופרסומות — לטעון אותם רק אחרי שהמשתמש כבר יכול לתקשר עם הדף.
<script defer src='analytics.js'>המילה defer אומרת: טעינה ברקע, הרצה רק אחרי שה-HTML מוכן. זה שומר את ה-Thread הראשי פנוי לתגובה לאינטראקציות מהמשתמש.
חשוב לבדוק: כמה סקריפטים של צד שלישי נטענים? לפעמים Google Tag Manager לבדו מזריק עשרות סקריפטים — כל אחד פוגע ב-INP. כדאי לעבור עם המפתח על רשימת הסקריפטים ולהסיר את מה שלא חיוני.
שיפור INP — חלוקת קוד
עיקרון נוסף לשיפור INP: לא לטעון את כל קוד ה-JavaScript של האתר בבת אחת בטעינה הראשונה. קוד שלא נחוץ בדף הנוכחי — למה לטעון אותו?
הטכניקה נקראת Code Splitting — חלוקת קוד לחבילות קטנות שנטענות רק כשצריך אותן. לדוגמה: קוד של עמוד צ'קאאוט לא צריך להיטען בדף הבית.
פלטפורמות כמו Next.js עושות Code Splitting אוטומטית — כל דף מקבל רק את הקוד שצריך לו. אם האתר שלכם בנוי על Next.js ועדיין יש בעיות INP — הסיבה לרוב תהיה סקריפטים של צד שלישי או רכיבים כבדים שנטענים גם בלא צריך.
INP בנייד — האתגר האמיתי
INP הרבה יותר בעייתי במכשירים ניידים מאשר במחשבים. מחשב ממוצע מריץ JavaScript 4-5 פעמים מהר יותר מטלפון ממוצע.
זה אומר שאתר שנראה מהיר ומגיב כשאתם בודקים מהמחשב שלכם — עלול לתת חוויה גרועה למשתמשים עם טלפון ישן יותר בחיבור רשת איטי.
גוגל מסתמכת בעיקר על נתוני נייד — ולכן ה-INP שמשפיע על הדירוג הוא בעיקר זה שנמדד על מכשירים ניידים. בדיקה מהמחשב שלכם תמיד תיתן תמונה אופטימית מדי.
INP ב-2026
ב-2026, INP הוא המדד שהכי הרבה אתרים מתקשים בו, כי הוא נוסף ב-2024 ועדיין הרבה אתרים לא הסתגלו אליו. אתרים שנבנו כ-SPA (Single Page Application) — כלומר אתרים שטוענים הכל דרך JavaScript — סובלים מ-INP גרוע יותר.
מגמה שמשפרת INP: מעבר לגישת Server-First — שרת שמחזיר HTML מוכן עם מינימום JavaScript. פלטפורמות כמו Next.js 15, SvelteKit ו-Astro בונות בגישה זו ומשיגות INP טוב יותר.
חידוש נוסף: יכולות AI שמוטמעות בדפדפן (סיכום, תרגום) מוסיפות קוד ועלולות לפגוע ב-INP — תחום שכדאי לעקוב אחריו.
שאלות נפוצות
רוצים יישום מקצועי?
המדריכים שלנו הם הבסיס — WAO מיישמת עבורכם.