Interaction to Next Paint (INP): How to Fix It in WordPress
TL;DR
INP (Interaction to Next Paint) replaced First Input Delay (FID) as a Core Web Vital in March 2024. Most WordPress sites fail it because heavy JavaScript plugins block the main thread when users click buttons or interact with forms — not because of server speed. The fix: audit plugin load, defer non-critical JavaScript, and replace heavy jQuery plugins with modern lightweight alternatives.
What INP Measures (And Why WordPress Fails)
INP measures the time from when a user clicks a button (or types in a form field) until the browser displays the response — a visual update, a menu opening, a form error, anything. Most WordPress sites fail INP not because the server is slow, but because the browser's main thread is blocked by JavaScript. A user clicks "Add to Cart," but three plugins are running event listeners, animations, and analytics code simultaneously. The browser cannot respond for 500–1000ms (or worse), and the page feels sluggish.
WordPress loads plugins in order, and most plugins do not use code splitting or lazy loading. A single heavy plugin (like some page builders, form plugins, or marketing automation integrations) can add 2-3MB of JavaScript that runs on every page, on every interaction, consuming main-thread time.
Core Web Vitals — drag to test your scores
2s
Largest Contentful Paint
180ms
Interaction to Next Paint
0.06
Cumulative Layout Shift
The Plugin Audit: Where the Time Is Going
Start here: open your site in Chrome DevTools (F12), go to Lighthouse, run a Performance audit. Scroll to "Unused JavaScript" — if more than 50% of your JS is marked as unused, you have a bloat problem. Next, go to the Network tab, sort by script size, and see which .js files are being loaded. Scripts from plugins like Elementor, Gravity Forms, WooCommerce add-ons, and ad networks often dwarf your core site script.
Then, ask hard questions: Does this plugin run on every page, or just a few? Can I defer loading it (async, defer, or load-on-demand)? Is there a lighter alternative? An example: if you use Gravity Forms only on your contact page, there is no reason to load its 400KB JavaScript on your homepage. Use the "Code Splitting" technique: load the plugin only when the form is present.
Deferring and Async Loading
WordPress loads scripts in the <head>, which blocks page rendering. Use the wp_enqueue_script() function's $in_footer parameter (set to true) to move scripts to the end of the <body>, so they load after the page content renders. For non-critical plugins (analytics, chat widgets, ads), add the async attribute so they load in parallel without blocking.
Critical fix for most WordPress sites: defer jQuery-dependent plugins until user interaction. Load jQuery immediately, but delay plugin initialization until the user clicks something or scrolls into view. This technique alone can drop INP from 600ms to 150ms on slow devices.
Replacing Heavy Plugins with Lightweight Alternatives
Some WordPress plugins are legacy codebases built before performance was a priority. Elementor, for example, loads 2–3MB of JS even if you only use it on one page. Modern page builders like Blocksy or even native WordPress blocks use 10x less code. Ad networks and chat widgets often have bloated SDKs. Consider: Do I need WooCommerce add-ons from 2015, or can I use modern headless API integrations?
For forms: Gravity Forms is heavy. Formstack, Netlify Forms, or even a lightweight custom solution (via Zapier or Make) handles 90% of SMB needs with 1/10th the code. For image optimization: remove Smush Pro (250KB JS) and use WP Rocket (included in many plans) or Imagify. For sliders: replace Revolution Slider with Swiper (vanilla JS, 10KB).
Measuring INP: How to Know You Fixed It
Use Google PageSpeed Insights (https://pagespeed.web.dev/) to check INP. A score below 200ms is "good"; above 500ms is failing. Use the Chrome User Experience Report data — not just Lighthouse local scores — because Lighthouse runs on your dev machine (fast), but real users on mobile (slow) tell the real story.
Set up Web Vitals monitoring (via Sentry, DataBox, or built-in Core Web Vitals in Google Search Console) to track real-user INP over time. A single audit is a snapshot; continuous monitoring shows whether your fix stuck or if new plugins re-introduced the problem.
FAQ
If I disable all plugins, INP goes down. Should I remove all of them?
No. Disable them one at a time and measure INP using Lighthouse after each. You will often find that 80% of plugins have zero impact on INP, but 3–5 heavy ones are the culprits. Keep the essential ones, remove the luxury ones. A plugin that adds a chat widget is nice; a plugin that adds 2MB of unused code is not.
Does INP only matter for clicks? What about form typing?
INP measures all interactions: clicks, taps, keyboard input, pointer events. A form field that lags when you type in it (e.g., 300ms delay before a character appears) is an INP failure. This often happens when auto-save, validation, or analytics listeners block the main thread. The fix is the same: defer or remove the heavy listeners.
Can I hire someone to fix INP for me?
Yes. A WordPress performance specialist can run the audits, recommend plugin replacements, and handle code changes in a few hours to a day. Budget ₪2,000–₪5,000 for a small site. The ROI is high: improved INP often correlates with 10–20% more conversions (faster interactions feel more responsive and build user confidence).