INP (Interaction to Next Paint): איך מתקנים את זה בוורדפרס
מאת דניאל משקוב, ארכיטקט מערכות AIפורסם עודכן 6 דק׳ קריאה
בקצרה
מדד INP (Interaction to Next Paint) החליף את FID (First Input Delay) כאחד ממדדי Core Web Vitals ב-12 במרץ 2024. כשאתר וורדפרס נכשל בו, הסיבה הרגילה היא JavaScript כבד של תוספים שתופס את ה-main thread בדיוק כשהגולשים לוחצים על כפתורים או ממלאים טפסים — ולא מהירות השרת. הפתרון: לבדוק מה כל תוסף טוען, לדחות JavaScript שאינו קריטי, ולהחליף תוספי jQuery כבדים בחלופות מודרניות וקלות.
מה INP מודד (ולמה אתרי וורדפרס נכשלים בו)
INP מודד כמה זמן עובר מהרגע שהגולש לוחץ על כפתור (או מקליד בשדה של טופס) ועד שהדפדפן מציג תגובה על המסך — שינוי ויזואלי, תפריט שנפתח, הודעת שגיאה בטופס, כל דבר. רוב אתרי הוורדפרס נכשלים ב-INP לא בגלל שהשרת איטי, אלא בגלל שה-main thread של הדפדפן עסוק בהרצת JavaScript. הגולש לוחץ על "הוספה לסל", אבל באותו רגע שלושה תוספים מריצים מאזיני אירועים, אנימציות וקוד אנליטיקה. הדפדפן לא מצליח להגיב במשך 500–1000 מילישניות (ולפעמים יותר), והאתר מרגיש תקוע.
וורדפרס טוען את התוספים אחד אחרי השני, ורוב התוספים לא משתמשים בפיצול קוד או בטעינה עצלה. תוסף כבד אחד (למשל בוני עמודים מסוימים, תוספי טפסים או חיבורים למערכות אוטומציה שיווקית) יכול להוסיף מאות קילובייטים של JavaScript שרצים בכל עמוד ובכל אינטראקציה, ותופסים את זמן ה-main thread.
מדדי ליבה — גררו לבדיקת הציון שלכם
2.1 שנ׳
טעינת התוכן העיקרי
180 מילישניות
תגובה לאינטראקציה
0.06
יציבות פריסה
בדיקת התוספים: לאן הולך הזמן
התחילו כאן: פתחו את האתר ב-Chrome DevTools (F12), עברו ללשונית Lighthouse והריצו בדיקת ביצועים. גללו לסעיף "Reduce unused JavaScript" — אם יותר מ-50% מה-JS שלכם מסומן כקוד שלא נמצא בשימוש, יש לכם עודף קוד. אחר כך עברו ללשונית Network, מיינו לפי גודל וראו אילו קובצי .js נטענים. הסקריפטים של תוספים כמו אלמנטור, Gravity Forms, תוספים לווקומרס ורשתות פרסום גדולים לא פעם בהרבה מהסקריפט של האתר עצמו.
עכשיו שאלו שאלות קשות: התוסף הזה רץ בכל עמוד, או רק בחלק מהם? אפשר לדחות את הטעינה שלו (async, defer, או טעינה רק כשצריך)? יש חלופה קלה יותר? דוגמה: Contact Form 7 טוען כברירת מחדל את הסקריפטים והעיצובים שלו בכל עמוד באתר — אם הטופס היחיד שלכם נמצא בעמוד צור קשר, אין שום סיבה לטעון אותם בדף הבית. טענו את הקבצים של כל תוסף רק בעמודים שבאמת משתמשים בו (טעינה מותנית), בכמה שורות קוד או בעזרת תוסף לניהול קבצים כמו Perfmatters או Asset CleanUp.
טעינה דחויה (defer) וטעינה אסינכרונית (async)
סקריפט שנרשם בלי הגדרות נטען בתוך ה-<head>, ושם הוא חוסם את הרינדור של העמוד ומתחרה באינטראקציות הראשונות של הגולש. כשאתם טוענים סקריפט עם wp_enqueue_script(), העבירו את in_footer כדי שייטען בסוף ה-<body>, ומאז וורדפרס 6.3 גם strategy עם הערך defer (או async לסקריפטים עצמאיים לגמרי, כמו אנליטיקה או ווידג'ט צ'אט). סקריפט דחוי יורד במקביל לעמוד ורץ רק אחרי שהדפדפן סיים לפענח את ה-HTML, כך שה-main thread מתפנה מוקדם יותר.
תיקון קריטי להרבה אתרי וורדפרס: דחו סקריפטים שאינם חיוניים — ווידג'טים של צ'אט, פופאפים, קודי מעקב שיווקיים — עד לאינטראקציה הראשונה של הגולש, ואתחלו תוספי jQuery רק כשהגולש מגיע לאזור שבו הם נדרשים. הסתייגות אחת: כל מה שדחיתם ירוץ ברגע האינטראקציה הראשונה, אז לעולם אל תדחו סקריפט שהלחיצה הראשונה עצמה תלויה בו — כך רק תעבירו את ההשהיה אל הלחיצה הזו. כשעושים את זה בזהירות, הטכניקה הזו לבדה יכולה לשפר את ה-INP משמעותית בטלפונים איטיים.
החלפת תוספים כבדים בחלופות קלות
חלק מתוספי הוורדפרס הם קוד ותיק שנכתב עוד לפני שמישהו חשב על ביצועים. בוני עמודים כמו אלמנטור מוסיפים שכבה משלהם של JavaScript ו-CSS לכל עמוד שנבנה איתם — הרבה יותר מאותו עיצוב שבנוי בבלוקים המובנים של וורדפרס על גבי תבנית קלה כמו Blocksy או GeneratePress. גם לרשתות פרסום ולווידג'טים של צ'אט יש לא פעם ערכות SDK מנופחות. שאלו את עצמכם: אנחנו באמת עדיין צריכים את תוספי הווקומרס האלה משנת 2015, או שווקומרס עצמו (או תוסף מודרני אחד) כבר עושה את מה שהם עשו?
טפסים: תוספי טפסים עתירי פיצ'רים טוענים סקריפטים כבדים, שלרוב תלויים ב-jQuery. תוסף טפסים קל יותר, או טופס HTML פשוט ששולח את הנתונים לאוטומציה (דרך Zapier או Make), מכסה את רוב הצרכים של עסק קטן או בינוני בחלק קטן מהקוד. תמונות: את הדחיסה עושים בזמן ההעלאה או בצד השרת (Imagify, ShortPixel או ה-CDN לתמונות של חברת האחסון), לא ב-JavaScript שרץ אצל הגולש — ומאז גרסה 5.5 וורדפרס מוסיף לתמונות את loading="lazy" בעצמו, כך שסקריפט נפרד לטעינה עצלה בדרך כלל מיותר. סליידרים: החליפו את Slider Revolution בספרייה קלה יותר כמו Swiper, או בקרוסלה מבוססת CSS scroll-snap שלא צריכה JavaScript בכלל.
מדידת INP: איך יודעים שהתיקון עבד
בדקו את ה-INP ב-Google PageSpeed Insights (https://pagespeed.web.dev/). לפי גוגל, INP של 200 מילישניות ומטה הוא "טוב", בין 200 ל-500 מילישניות "טעון שיפור", ומעל 500 מילישניות "גרוע" — והמדידה נעשית על האחוזון ה-75 של ביקורים אמיתיים. הנתון הזה מגיע מנתוני השטח שבראש הדוח (Chrome User Experience Report), והם מופיעים רק כשיש לאתר מספיק תנועה אמיתית. ציון המעבדה של Lighthouse שמתחתם לא מודד INP בכלל, כי בבדיקת מעבדה אף אחד לא לוחץ על כלום; המדד הכי קרוב שיש בו הוא Total Blocking Time. את התמונה האמיתית נותנים גולשים אמיתיים בטלפונים בינוניים, לא מחשב הפיתוח המהיר שלכם.
הגדירו ניטור של Web Vitals (דרך Sentry, ספריית web-vitals של גוגל, או דוח Core Web Vitals ב-Google Search Console) כדי לעקוב לאורך זמן אחרי ה-INP של גולשים אמיתיים. בדיקה בודדת היא תמונת מצב; ניטור רציף מראה אם התיקון החזיק או שתוספים חדשים החזירו את הבעיה.
שאלות נפוצות
איך מחושב INP?
הדפדפן מודד כל לחיצה, נגיעה והקשה בעמוד. זמן התגובה של כל אינטראקציה נמדד מהקלט ועד שהפריים הבא מצויר, והוא בנוי משלושה חלקים: השהיית קלט (המתנה ל-main thread), זמן עיבוד (הקוד שמטפל באירוע) והשהיית הצגה (הרינדור של התוצאה). ה-INP של העמוד הוא האינטראקציה האיטית ביותר — אלא שבעמודים עם הרבה אינטראקציות, לפי web.dev, מתעלמים מהאינטראקציה האיטית ביותר אחת על כל 50 כדי לסנן חריגים. אחר כך גוגל לוקחת את האחוזון ה-75 של ביקורים אמיתיים: 200 מילישניות ומטה זה טוב, מעל 500 זה גרוע. גלילה וריחוף לא נספרים.
כשאני משבית את כל התוספים, ה-INP משתפר. האם כדאי להסיר את כולם?
לא. השביתו אותם אחד אחד ובדקו שוב אחרי כל השבתה: פתחו את לשונית Performance ב-Chrome DevTools, שמציגה את ה-INP בזמן אמת בזמן שאתם לוחצים ומקלידים, וחזרו בכל פעם על אותן פעולות בדיוק (דוח Lighthouse רגיל לא מודד INP). בדרך כלל תגלו שלרוב התוספים יש השפעה זניחה על ה-INP, ושכמה תוספים כבדים בודדים הם האשמים. השאירו את החיוניים, והסירו את אלה שהם בגדר מותרות. תוסף שמוסיף ווידג'ט צ'אט זה נחמד; תוסף שמוסיף 2MB של קוד שאף אחד לא משתמש בו — לא.
האם INP חשוב רק ללחיצות? מה לגבי הקלדה בטפסים?
INP מודד לחיצות עכבר, נגיעות במסך מגע והקשות מקלדת — פיזית או על המסך. (ריחוף עם העכבר וגלילה לא נספרים.) שדה בטופס שמגיב באיטיות כשמקלידים בו (למשל עיכוב של 300 מילישניות עד שהאות מופיעה) הוא כשל ב-INP. זה קורה הרבה כשמאזינים של שמירה אוטומטית, בדיקת תקינות או אנליטיקה תופסים את ה-main thread. הפתרון זהה: לדחות או להסיר את המאזינים הכבדים.
האם אפשר לשכור מישהו שיתקן לי את ה-INP?
כן. מומחה ביצועים לוורדפרס יכול להריץ את הבדיקות, להמליץ אילו תוספים להחליף ולבצע את שינויי הקוד — באתר קטן זו בדרך כלל עבודה של כמה שעות עד יום, והמחיר תלוי בעיקר בכמה תוספים ותבניות מעורבים. התועלת מוחשית: חנות שמגיבה מיד ללחיצה על "הוספה לסל" ולהקלדה בטופס התשלום מאבדת פחות קונים בדרך. מדדו את שיעור ההמרה שלכם לפני התיקון ואחריו, במקום להסתמך על אחוז כללי שמישהו פרסם. תיקון כזה הוא חלק מעבודת הפיתוח והמהירות שלי בוורדפרס, עם הצעת מחיר קבועה אחרי בדיקה קצרה של האתר. רוצים קודם לראות איפה האתר שלכם עומד? עברו על צ'קליסט הביצועים.
מקורות
- Google web.dev — Interaction to Next Paint (checked October 2026)
- web.dev — Interaction to Next Paint becomes a Core Web Vital on March 12 (checked October 2026)
- Make WordPress Core — Registering scripts with async and defer attributes in WordPress 6.3 (checked October 2026)
- Make WordPress Core — Lazy-loading images in 5.5 (checked October 2026)
- Chrome DevTools — Performance panel: live Core Web Vitals, including INP (checked October 2026)
- PageSpeed Insights