If you have been tracking Core Web Vitals lately, you already know that the rules changed in March 2024. Google retired First Input Delay (FID) and promoted Interaction to Next Paint (INP) as the responsiveness metric that counts toward Search ranking signals. Yet many developers and site owners are still fighting the old battle, optimizing for FID while their INP scores quietly drag down their performance grades.
This guide covers everything you need to know: what INP actually measures, why it is a stricter and more meaningful signal than FID, the thresholds you must hit, the most common causes of poor scores, and the concrete fixes that work in 2026 — including specific guidance for WordPress and WooCommerce sites.
What Is Interaction to Next Paint?
According to web.dev, Interaction to Next Paint measures the latency of all interactions a user makes with a page during their entire visit, then reports the single worst interaction latency as the page’s INP score. An interaction covers mouse clicks, keyboard presses, and touchscreen taps — anything that triggers a visual response from the browser.
The metric captures the full pipeline: the time from when the user first interacts to when the browser finishes painting the next frame in response. That includes event handler execution, any rendering work the JavaScript triggers, and the final presentation update on screen.
Why INP Replaced FID
FID only measured the input delay of the very first interaction on a page — the time the browser waited before it could even start processing the event. It ignored how long the handler actually ran and it ignored every interaction after the first one. A page could have a great FID score yet feel sluggish throughout the entire user session.
As Google explained in the INP Core Web Vitals launch post, INP is a more complete picture of responsiveness. It evaluates the full duration of each interaction and uses the worst-case result, so it cannot be gamed by a fast first load while the rest of the experience lags.
The INP Thresholds You Need to Know
Google defines three performance bands for INP. These apply at the 75th percentile of real user sessions in the Chrome UX Report (CrUX) dataset:
| Rating | INP Value | User Experience |
|---|---|---|
| Good | Under 200 ms | Interactions feel immediate and responsive |
| Needs Improvement | 200 ms – 500 ms | Noticeable lag; users may hesitate or retry |
| Poor | Above 500 ms | Frustrating delays; high abandonment risk |
The 200 ms target is tighter than most developers expect. Half a second — the Poor threshold — sounds fast in human terms, but in browser performance terms it is an eternity that users absolutely feel. Research consistently shows that how speed impacts conversion is direct and significant: every 100 ms of added latency measurably reduces engagement.
Field Data vs. Lab Data: How INP Is Measured
There are two categories of INP measurement you need to understand.
Field Data (Real User Monitoring)
Field data comes from actual users interacting with your site. Google’s primary field data source is Chrome UX Report (CrUX), which aggregates anonymized performance data from Chrome users who have opted in to sharing browser statistics. CrUX data powers the Core Web Vitals report in Google Search Console and PageSpeed Insights. Your official INP score for ranking purposes comes from this field data at the 75th percentile.
For continuous monitoring, tools like the web-vitals JavaScript library let you collect INP in your own analytics pipeline. This is the most actionable data because it reflects real interaction patterns on your specific site with your real users.
Lab Data (Synthetic Testing)
Lab tools like Lighthouse, WebPageTest, and Chrome DevTools simulate interactions in a controlled environment. Lab data is essential for development and debugging — you can reproduce issues on demand and profile the main thread — but lab INP scores may differ from field scores because they cannot replicate the full variety of real user interaction patterns and device conditions.
Use lab data to diagnose and fix problems. Use field data to confirm that fixes actually improved the experience for real users.
What Causes Poor INP Scores
Most INP problems trace back to the same set of root causes. Understanding them makes fixes straightforward.
Long Tasks on the Main Thread
The browser’s main thread handles JavaScript execution, style calculations, layout, and painting. When a long task (any task exceeding 50 ms) is running, the browser cannot process user input. If a user clicks a button while a 300 ms JavaScript task is executing, that entire 300 ms adds to the interaction latency. According to web.dev’s long tasks guidance, breaking up these tasks is the single highest-leverage INP optimization.
Heavy JavaScript Bundles
Large JavaScript bundles take time to parse and compile, creating long tasks during page load that block interactions. Even after load, heavyweight frameworks or feature-rich libraries can trigger expensive recalculations in response to every user action.
Large DOM Size
A DOM with tens of thousands of nodes makes style recalculation and layout significantly more expensive. Every interaction that triggers a reflow — a button state change, a dropdown opening — becomes slower as DOM size grows. Google recommends keeping total DOM node counts under 1,400.
Unoptimized Event Handlers
Event handlers that perform synchronous heavy work — DOM queries, complex calculations, synchronous network calls — directly inflate interaction duration. Handlers that trigger large layout recalculations or paint large areas of the screen compound the problem.
Third-Party Scripts
Analytics tags, advertising pixels, chat widgets, and A/B testing scripts often run long tasks that compete with interaction handling on the main thread. A single poorly-timed third-party script execution can push an otherwise Good INP score into the Poor range.
Vilee LLC combines deep technical expertise in WordPress/WooCommerce development with AI-powered automation to operate 520+ profitable online businesses at scale.
How to Fix Poor INP: A Developer Checklist
The following fixes address the root causes above. Apply them in order of impact for your specific site.
- Break up long tasks. Identify tasks over 50 ms in the Chrome DevTools Performance panel or with
PerformanceObserverand the Long Tasks API. Refactor synchronous loops and heavy computations into smaller chunks. - Yield to the main thread. After each chunk of work, yield control back to the browser so it can process pending input. The modern approach is
scheduler.yield()(available in Chrome 129+). The fallback for broader compatibility is wrapping deferred work insetTimeout(fn, 0)orMessageChannelposts. - Defer non-critical JavaScript. Use
deferandasyncattributes on script tags. Load analytics, chat widgets, and advertising scripts after the page is interactive, not during initial load. - Reduce JavaScript bundle size. Audit your dependencies with tools like
webpack-bundle-analyzer. Remove unused libraries, implement code splitting, and lazy-load routes and components that are not needed on first interaction. - Optimize event handlers. Keep handler functions lean. Move heavy computation off the main thread using Web Workers. Debounce or throttle handlers that fire on high-frequency events like scroll or resize.
- Minimize DOM size. Virtualize long lists (render only visible items). Remove hidden elements from the DOM rather than hiding them with CSS when they are not needed.
- Audit and limit third-party scripts. Use the Network panel to identify third-party domains. Remove scripts that are no longer providing value. Load remaining scripts with
async/deferor use a facade pattern to delay loading until user interaction. - Use
content-visibility: auto. This CSS property lets the browser skip rendering off-screen content, reducing layout work triggered by interactions near the fold.
WordPress and WooCommerce: Specific Causes and Fixes
WordPress and WooCommerce sites have a distinct set of INP challenges because of how the ecosystem is structured. For a deeper overview, see our guide to Core Web Vitals for WooCommerce.
Heavy Page Builder Themes
Page builders like Elementor, Divi, and WPBakery generate deeply nested DOM structures and load large JavaScript runtimes. A standard Elementor build can produce a DOM with 3,000–8,000 nodes and load 300–600 KB of JavaScript before any plugins are added. Switching to a lightweight block theme (Kadence, GeneratePress, or a custom FSE theme) is often the highest-impact INP fix for WordPress sites.
Plugin Accumulation
Each active plugin can add JavaScript that runs on every page load. Form plugins, popup builders, slider plugins, and review systems each contribute event listeners and initialization code. Audit active plugins and dequeue scripts on pages where they are not needed using wp_dequeue_script().
WooCommerce Cart and Checkout Interactivity
Add-to-cart buttons, quantity selectors, variation pickers, and the AJAX mini-cart are frequent sources of poor INP on WooCommerce stores. These handlers often trigger cart fragment updates that involve large portions of the page. Optimize by deferring fragment updates, caching cart HTML, and ensuring handler functions yield before performing DOM updates.
Tracking and Analytics Scripts
WooCommerce stores typically run Google Analytics 4, Meta Pixel, Pinterest Tag, TikTok Pixel, and Klaviyo simultaneously. Each fires JavaScript on interaction events. Load all tracking scripts through Google Tag Manager with a page-idle trigger, or use server-side tagging to move tracking load off the main thread entirely.
Monitoring INP Continuously
INP is not a set-and-forget metric. New plugins, theme updates, and third-party script changes can silently degrade your score between audits. Implement the web-vitals library to send INP data to your analytics platform on every session. Set up alerts when the 75th percentile exceeds 200 ms. Review Google Search Console’s Core Web Vitals report weekly to catch regressions before they affect your search performance.
For a full technical walkthrough of optimization strategies and how they connect to revenue outcomes, explore our services or contact our performance team for a site-specific audit.
Sources
- web.dev — Interaction to Next Paint (INP)
- web.dev — Optimize INP
- web.dev — INP Core Web Vitals Launch
- Google Search Central — Introducing INP
- MDN Web Docs — Interaction to Next Paint
- Chrome for Developers — CrUX Metrics Methodology
- web.dev — Optimize Long Tasks
Frequently Asked Questions
What is the Good threshold for Interaction to Next Paint?
A Good INP score is under 200 milliseconds at the 75th percentile of real user sessions. Scores between 200 ms and 500 ms need improvement, and scores above 500 ms are considered Poor.
How does INP differ from First Input Delay?
FID only measured the delay before the browser could start processing the very first user interaction, and it ignored all subsequent interactions. INP measures the full latency of every interaction during a visit and reports the worst result, making it a far more accurate measure of overall page responsiveness.
Why is my WordPress site failing INP even though it passed FID?
WordPress sites commonly fail INP due to heavy page builder JavaScript, large plugin footprints, WooCommerce cart handler overhead, and multiple third-party tracking scripts running simultaneously. These factors create long tasks on the main thread that block the browser from responding to interactions quickly. Auditing and deferring non-critical scripts is usually the fastest path to improvement.
