מה INP באמת מודד — ולמה הוא החליף את FID
INP (Interaction to Next Paint) מודד את הזמן מכל אינטראקציה של משתמש — קליק, לחיצה, הקשת מקש — עד הרגע שבו הדפדפן מציג עדכון ויזואלי בתגובה. ציון INP טוב הוא מתחת ל-200ms. כל דבר מעל 500ms הוא "גרוע" וגורר את הערכת שלכם כלפי מטה.
FID — מה ש-INP החליף — מדד רק את העיכוב באינטראקציה הראשונה בלבד. אם האתר שלכם הגיב לאט לקליק הראשון אבל מהר לכל דבר לאחר מכן, FID נראה מצוין. INP מודד כל אינטראקציה לאורך כל ביקור הדף ומדווח על הגרועה ביותר. זהו ייצוג הרבה יותר כנה של כמה מגיב האתר שלכם בפועל.
ההשלכה המעשית: אתר יכול להיות עם LCP מצוין (נטעין מהר) ועדיין להיכשל ב-INP בצורה גרועה. מהירות טעינה ורספונסיביות אינטראקציה הן בעיות נפרדות עם סיבות נפרדות.
למה אתרי WordPress ספציפית מתקשים עם INP
הסיבה השורשית כמעט תמיד זהה: יותר מדי JavaScript שרץ על בטעינת הדף. אתרי WordPress צוברים JavaScript מתוספים. כל תוסף טפסים, כל ווידג'ט צ'אט, כל ספריית אנליטיקה, כל page builder מוסיף JavaScript שרץ בטעינה — ללא קשר לאם הוא נדרש בעמוד הזה.
הסיבה השנייה היא עומס של event handlers. כשמשתמש לוחץ על כפתור, הדפדפן צריך להריץ את ה-click handler, לחשב מחדש את הפריסה ולצייר את התוצאה. אם ה-click handler מפעיל פונקציית JavaScript גדולה — או שה-main thread כבר עסוק במשהו אחר — העיכוב מתצבר.
הסיבה השלישית היא סקריפטים של צד שלישי. Google Tag Manager שטוען שישה פיקסלים שיווקיים, ווידג'ט צ'אט חי שמאותחל, ספריית הסכמת עוגיות שמנתחת — כל זה רץ על ה-main thread ומעכב כל אינטראקציה בדף.
איך לאבחן את ציון ה-INP שלכם
התחילו עם נתוני משתמשים אמיתיים, לא נתוני מעבדה. גשו ל- → Core Web Vitals. זה מציג את ציון ה-INP שלכם ממבקרים אמיתיים, לא בדיקות מדומות. אם אין לכם מספיק תנועה לנתוני CrUX, השתמשו ב-PageSpeed Insights על הדפים המרכזיים שלכם.
כדי למצוא את האינטראקציות הספציפיות הגורמות ל-INP גרוע, פתחו Chrome DevTools → לשונית Performance → הקליטו תוך כדי לחיצה על האלמנטים שמשתמשים מקיישים איתם הכי הרבה (תפריטי ניווט, כפתורי הוספה לסל, שדות קלט טפסים, מפתחי accordion). חפשו משימות ארוכות (פסים אדומים בציר הזמן של ה-main thread) המתרחשות מיד לאחר הקליק.
תוסף Web Vitals ל-Chrome גם שימושי — הוא מדווח על INP בזמן אמת בזמן שאתם מקיישים עם הדף, ומדגיש איזו אינטראקציה גרמה לציון הגרוע ביותר.
התיקונים הספציפיים ל-WordPress שבאמת משפיעים על הציון
תיקון 1 — בקרו והסירו JavaScript שנטעין בכל עמוד. ב-WordPress, תוספים טוענים את הסקריפטים שלהם באופן גלובלי אלא אם כן נאמר להם במפורש לא. השתמשו ב- או Perfmatters כדי להשבית סקריפטים בעמודים שבהם הם לא ממלאים שום תפקיד. תוסף טפסי קשר שטוען את ה-JavaScript שלו בדף הבית הוא בזבוז main thread טהור.
תיקון 2 — דחו סקריפטים של צד שלישי. Google Tag Manager, ווידג'טי צ'אט ופיקסלים שיווקיים לא צריכים לרוץ לפני שהדף אינטראקטיבי. העבירו אותם לטעינה אחרי שהדף מוצג במלואו באמצעות מנהל סקריפטים שתומך ב"טעינה מושהית" — Perfmatters, WP Rocket, או פתרון מותאם אישית.
תיקון 3 — החליפו JavaScript כבד של page builder בבלוקים מקוריים או חלופות קלות. Elementor שולח JavaScript משמעותי בכל עמוד. אם האתר שלכם משתמש ב-Elementor אבל צריך אותו רק לפריסה (לא לווידג'טים אינטראקטיביים), שקלו להעביר תבניות מרכזיות לבלוקי Gutenberg.
תיקון 4 — פצלו משימות JavaScript ארוכות. אם יש לכם JavaScript מותאם אישית שמריץ פונקציה גדולה על קליק משתמש, ארגנו מחדש כדי לוותר לדפדפן בין שלבים באמצעות setTimeout(fn, 0) או scheduler.yield() (זמין ב-Chrome 115+).
איך נראה שיפור INP ריאליסטי
בחנות WooCommerce שביקרתי בשנה שעברה, INP היה ב-680ms — בטווח ה"גרוע". הסיבה: Elementor שטוען 340KB של JavaScript בכל עמוד, תוסף צ'אט חי שמאותחל שלוש קריאות API בטעינה, וספריית הסכמת עוגיות שחסמה את ה-main thread למשך ~200ms בכל ביקור דף.
התיקונים שיושמו: עברנו את עמודי המוצר והתשלום מ-Elementor לבלוקי Gutenberg מותאמים אישית (צמצום עומס ה-JS בכ-280KB), דחינו את ווידג'ט הצ'אט עד אחרי האינטראקציה הראשונה של המשתמש, והחלפנו את ספריית ההסכמה ביישום קל יותר. תוצאה: INP ירד ל-140ms. האתר עבר מנכשל ל"טוב" מבלי לגעת בשרת או בתוכנית האחסון.
הנקודה היא לא שהתיקון שלכם יהיה זהה. היא שבעיות INP הן כמעט תמיד בעיות JavaScript — ובעיות JavaScript ב-WordPress הן כמעט תמיד בעיות תוספים. השרת כמעט לעולם אינו צוואר הבקבוק.
INP ו-WooCommerce: האינטראקציות הספציפיות לשמור עליהן
לאתרי WooCommerce יש אינטראקציות רגישות ל-INP במיוחד: כפתור הוספה לסל, בוחרי כמות, תפריטי וריאציה (מידה, צבע), וטופס התשלום. אלו אינטראקציות בסיכון גבוה שבהן עיכוב של 500ms נראה למשתמש ופוגע בהמרות.
עיכוב הוספה לסל ב-WooCommerce נגרם לעתים קרובות מה-AJAX handler שנחסם על ידי JavaScript אחר. בדקו אילו סקריפטים נטעינים בדפי מוצר וסלקו כל דבר שלא תורם לזרימת הרכישה. בדקו את הגדרת — אם אתם לא מציגים מיני-סל, השבתת זה מסירה קריאת AJAX אחת לכל טעינת דף.
תפריטי וריאציה שגורמים לעדכוני UI איטיים הם מקור נפוץ נוסף. אם שינוי וריאנט מוצר גורם לפיגור נראה לעין לפני שהמחיר או התמונה מתעדכנים, ה-JavaScript שמטפל באירוע הזה הוא ריצה ארוכה. פרופילו אותו ב-DevTools וחפשו פעולות DOM סינכרוניות שניתן לפצל או לנסות.
האתר שלכם נכשל ב-Core Web Vitals?
אני מאבחן לפני שנוגע בכלום. ספרו לי על המצב הנוכחי ואזהה בדיוק מה גורם לציון שלכם — ומה יידרש כדי לתקן אותו.
התחילו את הבריףמקורות
- 1Google — Interaction to Next Paint (web.dev, 2024) — INP הפך ל-Core Web Vital במרץ 2024, החליף את FID. ציון INP טוב הוא מתחת ל-200ms; מעל 500ms הוא "גרוע" ומשפיע על הערכות דירוג חיפוש.
- 2Chrome User Experience Report (CrUX, Q1 2025) — כ-35% מהאתרים ברחבי העולם בעלי ציוני INP גרועים — שיעור כישלון גבוה משמעותית מ-LCP או CLS, המשקף כמה אתרים טרם טיפלו בחביון אינטראקציה.
- 3Web Almanac 2024 (HTTP Archive) — JavaScript הוא התורם הבודד הגדול ביותר לזמן חסימת ה-main thread. דף WordPress חציוני טוען 540KB של JavaScript — יותר מכפול מהתקציב המומלץ ל-INP טוב.
- 4Google Search Central — Core Web Vitals ranking signal — Core Web Vitals הם אות דירוג מאושר של Google. אתרים בטווח ה"טוב" בכל שלושת המדדים מקבלים יתרון דירוג חיובי על פני עמודים שווי ערך עם ציונים "גרועים".
- 5Perfmatters Plugin Documentation — Script Manager — השבתת JavaScript לכל עמוד היא אחת מהתערבויות INP היעילות ביותר עבור אתרי WordPress, לעתים קרובות מצמצמת זמן חסימת ה-main thread ב-30–60% בדפים שבהם סקריפטים של צד שלישי אינם נדרשים.