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 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 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 → 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 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 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.
Your site failing Core Web Vitals?
I diagnose before I touch anything. Tell me your current setup and I will identify exactly what is causing your score — and what it will take to fix it.
Start the briefSources
- 1Google — Interaction to Next Paint (web.dev, 2024) — INP became a Core Web Vital in March 2024, replacing FID. A good INP score is under 200ms; above 500ms is "poor" and impacts search ranking assessments.
- 2Chrome User Experience Report (CrUX, Q1 2025) — Approximately 35% of websites globally have poor INP scores — a significantly higher failure rate than LCP or CLS, reflecting how many sites have not yet addressed interaction latency.
- 3Web Almanac 2024 (HTTP Archive) — JavaScript is the single largest contributor to main thread blocking time. The median WordPress page loads 540KB of JavaScript — more than double the recommended budget for good INP.
- 4Google Search Central — Core Web Vitals ranking signal — Core Web Vitals are a confirmed Google ranking signal. Sites in the "good" range for all three metrics receive a positive ranking benefit over equivalent pages with "poor" scores.
- 5Perfmatters Plugin Documentation — Script Manager — Per-page JavaScript disabling is one of the most effective INP interventions for WordPress sites, often reducing main thread blocking time by 30–60% on pages where third-party scripts are not needed.