Interaction to Next Paint (INP): How to Fix It in WordPress

What INP actually measures — and why it replaced FID

INP (Interaction to Next Paint) measures the time from any user interaction — a click, a tap, a key press — to the moment the browser renders a visual update in response. A good INP score is under 200ms. Anything above 500ms is "poor" and will drag down your Core Web Vitals assessment.

FID — what INP replaced — only measured the delay on the very first interaction. If your site responded slowly to the first click but fast to everything after, FID looked fine. INP measures every interaction throughout the entire page visit and reports the worst one. It is a far more honest representation of how responsive your site actually feels.

The practical implication: a site can have an excellent LCP (loads fast) and still fail INP badly. Loading speed and interaction responsiveness are separate problems with separate causes.

Why WordPress sites specifically struggle with INP

The root cause is almost always the same: too much JavaScript running on the main thread at page load. WordPress sites accumulate JavaScript from plugins. Every form plugin, every chat widget, every analytics library, every page builder adds JavaScript that runs on load — regardless of whether it is needed on that page.

The second cause is event handler overhead. When a user clicks a button, the browser needs to run the click handler, recalculate layout, and paint the result. If the click handler triggers a large JavaScript function — or if the main thread is already busy with something else — the delay compounds.

The third cause is third-party scripts. Google Tag Manager loading six marketing pixels, a live chat widget initialising, a cookie consent library parsing — all of this runs on the main thread and delays every interaction on the page.

How to diagnose your INP score

Start with real user data, not lab data. Go to Google Search Console → Core Web Vitals. This shows your INP score from real visitors, not simulated tests. If you do not have enough traffic for CrUX data, use PageSpeed Insights on your key pages — it will show both lab and field data where available.

To find the specific interactions causing poor INP, open Chrome DevTools → Performance tab → record while clicking the elements users interact with most (navigation menus, add-to-cart buttons, form inputs, accordion toggles). Look for long tasks (red bars in the main thread timeline) that occur immediately after your click.

The Web Vitals Chrome extension is also useful — it reports INP in real time as you interact with the page, and highlights which interaction triggered the worst score. Install it, browse your site as a user would, and note which interactions feel sluggish.

The WordPress-specific fixes that actually move the score

Fix 1 — Audit and remove JavaScript that loads on every page. In WordPress, plugins load their scripts globally unless explicitly told not to. Use Asset CleanUp or Perfmatters to disable scripts on pages where they serve no function. A contact form plugin loading its JavaScript on your homepage is pure main thread waste.

Fix 2 — Defer third-party scripts. Google Tag Manager, chat widgets, and marketing pixels do not need to run before the page is interactive. Move them to load after the page is fully rendered using a script manager that supports "delayed loading" — Perfmatters, WP Rocket, or a custom solution. The interaction delay caused by a live chat widget loading eagerly on every page visit is a known INP killer.

Fix 3 — Replace heavy page builder JavaScript with native blocks or lightweight alternatives. Elementor ships significant JavaScript on every page. If your site uses Elementor but only needs it for layout (not interactive widgets), consider migrating key templates to Gutenberg blocks. The JavaScript footprint difference is substantial.

Fix 4 — Break up long JavaScript tasks. If you have custom JavaScript that runs a large function on user click, restructure it to yield to the browser between steps using setTimeout(fn, 0) or scheduler.yield() (available in Chrome 115+). This allows the browser to render a frame before continuing — which is exactly what INP measures.

What a realistic INP improvement looks like

On a WooCommerce store I audited last year, INP was at 680ms — in the "poor" range. The cause: Elementor loading 340KB of JavaScript on every page, a live chat plugin initialising three API calls on load, and a cookie consent library that blocked the main thread for ~200ms on every page visit.

The fixes applied: switched the product and checkout pages from Elementor to custom Gutenberg blocks (reducing JS load by ~280KB), delayed the chat widget until after first user interaction, and replaced the consent library with a lighter implementation. Result: INP dropped to 140ms. The site went from failing to "good" without touching the server or hosting plan.

The point is not that your fix will be identical. It is that INP problems are almost always JavaScript problems — and JavaScript problems in WordPress are almost always plugin problems. The server is rarely the bottleneck.

INP and WooCommerce: the specific interactions to watch

WooCommerce sites have particularly INP-sensitive interactions: the Add to Cart button, quantity selectors, variation dropdowns (size, colour), and the checkout form. These are high-stakes interactions where a 500ms delay is user-visible and conversion-damaging.

Add to Cart delay in WooCommerce is frequently caused by the AJAX handler being blocked by other JavaScript. Check what scripts load on product pages and eliminate anything that does not contribute to the purchase flow. Use the WooCommerce cart fragments setting — if you are not showing a mini-cart, disabling this removes one AJAX call per page load.

Variation dropdowns that trigger slow UI updates are another common source. If changing a product variant causes a visible lag before the price or image updates, the JavaScript handling that event is long-running. Profile it in DevTools and look for synchronous DOM operations that could be broken up or debounced.