INP (Interaction to Next Paint): איך מתקנים את זה בוורדפרס
TL;DR
מדד INP (Interaction to Next Paint) החליף את First Input Delay (FID) כאחד ממדדי Core Web Vitals במרץ 2024. רוב אתרי הוורדפרס נכשלים בו כי תוספי JavaScript כבדים חוסמים את ה-main thread כשמשתמשים לוחצים על כפתורים או מקיימים אינטראקציה עם טפסים — ולא בגלל מהירות השרת. התיקון: לבדוק את עומס התוספים, לדחות JavaScript לא קריטי, ולהחליף תוספי jQuery כבדים בחלופות מודרניות וקלות.
מה INP מודד (ולמה וורדפרס נכשל בו)
INP מודד את הזמן מהרגע שבו המשתמש לוחץ על כפתור (או מקליד בשדה טופס) ועד שהדפדפן מציג את התגובה — עדכון ויזואלי, פתיחת תפריט, שגיאת טופס, כל דבר. רוב אתרי הוורדפרס נכשלים ב-INP לא בגלל שהשרת איטי, אלא בגלל שה-main thread של הדפדפן חסום על ידי JavaScript. המשתמש לוחץ על "הוסף לעגלה", אבל שלושה תוספים מריצים בו-זמנית מאזיני אירועים, אנימציות וקוד אנליטיקה. הדפדפן לא מצליח להגיב במשך 500–1000ms (או גרוע מכך), והעמוד מרגיש איטי וכבד.
וורדפרס טוען את התוספים לפי סדר, ורוב התוספים לא משתמשים בפיצול קוד או בטעינה עצלה. תוסף כבד אחד (למשל בוני עמודים מסוימים, תוספי טפסים, או אינטגרציות של אוטומציה שיווקית) יכול להוסיף 2-3MB של JavaScript שרצים בכל עמוד ובכל אינטראקציה, ומכלים את זמן ה-main thread.
מדדי ליבה — גררו לבדיקת הציון שלכם
2s
טעינת התוכן העיקרי
180ms
תגובה לאינטראקציה
0.06
יציבות פריסה
ביקורת התוספים: לאן הזמן הולך
התחילו כאן: פתחו את האתר ב-Chrome DevTools (F12), עברו ל-Lighthouse והריצו ביקורת ביצועים. גללו אל "Unused JavaScript" — אם יותר מ-50% מה-JS שלכם מסומן כלא בשימוש, יש לכם בעיית עומס מיותר. אחר כך עברו ללשונית Network, מיינו לפי גודל הסקריפט וראו אילו קובצי .js נטענים. סקריפטים מתוספים כמו אלמנטור, Gravity Forms, תוספי ווקומרס ורשתות פרסום לרוב מגמדים את הסקריפט המרכזי של האתר שלכם.
עכשיו שאלו שאלות קשות: האם התוסף הזה רץ בכל עמוד או רק בכמה? האם אפשר לדחות את הטעינה שלו (async, defer, או טעינה לפי דרישה)? האם יש חלופה קלה יותר? דוגמה: אם אתם משתמשים ב-Gravity Forms רק בעמוד יצירת הקשר, אין שום סיבה לטעון את 400KB ה-JavaScript שלו בדף הבית. השתמשו בטכניקת "Code Splitting": טענו את התוסף רק כשהטופס מופיע בעמוד.
טעינה דחויה וטעינת Async
וורדפרס טוען סקריפטים בתוך ה-<head>, מה שחוסם את רינדור העמוד. השתמשו בפרמטר $in_footer של הפונקציה wp_enqueue_script() (מוגדר ל-true) כדי להעביר סקריפטים לסוף ה-<body>, כך שהם ייטענו אחרי שתוכן העמוד עולה. עבור תוספים לא-קריטיים (אנליטיקה, ווידג'טים של צ'ט, פרסומות), הוסיפו את המאפיין async כדי שהם ייטענו במקביל מבלי לחסום.
תיקון קריטי לרוב אתרי הוורדפרס: דחו את התוספים התלויים ב-jQuery עד לאינטראקציה הראשונה של המשתמש. טענו את jQuery מיד, אבל דחו את אתחול התוסף עד שהמשתמש לוחץ על משהו או גולל אל האזור. רק הטכניקה הזו לבדה יכולה להוריד את ה-INP מ-600ms ל-150ms במכשירים איטיים.
החלפת תוספים כבדים בחלופות קלות
חלק מתוספי הוורדפרס הם בסיסי קוד מיושנים שנבנו לפני שביצועים הפכו לעדיפות. אלמנטור, למשל, טוען 2–3MB של JS גם אם אתם משתמשים בו בעמוד אחד בלבד. בוני עמודים מודרניים כמו Blocksy, ואפילו הבלוקים המובְנים של וורדפרס, משתמשים בפי 10 פחות קוד. לרשתות פרסום ולווידג'טים של צ'ט יש לעתים קרובות ערכות SDK נפוחות. שקלו: האם אני באמת צריך תוספי ווקומרס משנת 2015, או שאפשר להשתמש באינטגרציות API מודרניות בגישת headless?
לטפסים: Gravity Forms הוא תוסף כבד. Formstack, Netlify Forms, או אפילו פתרון מותאם וקל (דרך Zapier או Make) מכסים 90% מהצרכים של עסק קטן-בינוני בעשירית מהקוד. לאופטימיזציית תמונות: הסירו את Smush Pro (250KB של JS) והשתמשו ב-WP Rocket (כלול בחבילות רבות) או ב-Imagify. לסליידרים: החליפו את Revolution Slider ב-Swiper (vanilla JS, 10KB בלבד).
מדידת INP: איך לדעת שתיקנתם
השתמשו ב-Google PageSpeed Insights (https://pagespeed.web.dev/) כדי לבדוק INP. ציון מתחת ל-200ms נחשב "טוב"; מעל 500ms זה כישלון. הסתמכו על נתוני Chrome User Experience Report — ולא רק על הציון המקומי של Lighthouse — כי Lighthouse רץ על מכונת הפיתוח שלכם (מהירה), בעוד שמשתמשים אמיתיים בנייד (איטי) הם אלה שמספרים את הסיפור האמיתי.
הגדירו ניטור של Web Vitals (דרך Sentry, DataBox, או דוח Core Web Vitals המובנה ב-Google Search Console) כדי לעקוב אחרי ה-INP של משתמשים אמיתיים לאורך זמן. ביקורת בודדת היא תמונת מצב; ניטור מתמשך מגלה אם התיקון החזיק מעמד או שתוספים חדשים החזירו את הבעיה.
שאלות נפוצות
כשאני משבית את כל התוספים, ה-INP משתפר. האם כדאי להסיר את כולם?
לא. השביתו אותם אחד-אחד ומדדו את ה-INP ב-Lighthouse אחרי כל השבתה. לרוב תגלו של-80% מהתוספים אין שום השפעה על ה-INP, אבל 3–5 תוספים כבדים הם האשמים. השאירו את החיוניים, הסירו את המיותרים. תוסף שמוסיף ווידג'ט צ'ט הוא נחמד; תוסף שמוסיף 2MB של קוד לא בשימוש — לא.
האם INP חשוב רק ללחיצות? מה לגבי הקלדה בטפסים?
INP מודד את כל סוגי האינטראקציה: לחיצות, הקשות, קלט מקלדת ואירועי מצביע (pointer). שדה טופס שמשתהה כשמקלידים בו (למשל עיכוב של 300ms לפני שהתו מופיע) הוא כשל ב-INP. זה קורה לעתים קרובות כשמאזיני שמירה אוטומטית, ולידציה או אנליטיקה חוסמים את ה-main thread. התיקון זהה: לדחות או להסיר את המאזינים הכבדים.
האם אפשר לשכור מישהו שיתקן לי את ה-INP?
כן. מומחה ביצועים לוורדפרס יכול להריץ את הביקורות, להמליץ על החלפת תוספים ולבצע את שינויי הקוד בתוך כמה שעות עד יום. הקציבו ₪2,000–₪5,000 לאתר קטן. ה-ROI גבוה: שיפור ב-INP מתואם לעתים קרובות עם 10–20% יותר המרות (אינטראקציות מהירות מרגישות תגובתיות יותר ובונות אמון אצל המשתמש).