INP Core Web Vitals.
Interaction to Next Paint became the responsiveness Core Web Vital on March 12, 2024, replacing First Input Delay. The metric returns the slowest interaction-to-paint latency across the page session, capturing sustained main-thread blocking that FID's first-interaction sampling missed. The good threshold is 200 milliseconds; the needs-improvement band runs to 500 milliseconds.
INP work is one of the harder Core Web Vitals to fix because the slowest interaction lives somewhere in the interaction graph, and finding it is half the work. The diagnostic stage of Grove isolates the failing surface before any engineering hours go into the fix.
The slowest interaction-to-paint latency, across the page session.
Interaction to Next Paint measures the latency between every user interaction and the next visual update the browser paints. A click, a key press, a tap. The metric captures the time from the input event firing to the browser rendering the result of the handler. The reported INP for the page session is the slowest such latency, with a small allowance for outliers on heavily-interactive pages.
The threshold bands at the 75th percentile of field data: 200 milliseconds or under sits in good, between 200 and 500 milliseconds in needs-improvement, above 500 milliseconds in poor. The 200-millisecond ceiling reflects the perceptual threshold beyond which users perceive the interaction as laggy rather than immediate. The 500-millisecond ceiling above which the page enters poor reflects the threshold above which users perceive the interaction as broken.
The replacement of First Input Delay was the operational change. FID measured only the input delay portion of the first interaction. INP measures the full interaction-to-paint cycle across every interaction. Sites that scored green on FID and now sit in needs-improvement on INP are surfacing a real responsiveness problem that FID's sampling model could not see.
Bundle size, third-party tags, event-handler discipline.
JavaScript bundle size on the interaction paths is the first surface. Large synchronous bundles block the main thread when the interaction handler fires. Code splitting, lazy loading, and dead-code elimination shrink the surface area the handler runs against. The interaction path that fails INP is rarely the page-load path; the work is in the handler that runs at click time rather than the bundle that ships at first paint.
Third-party tag latency is the second surface. Analytics, advertising, tag managers, and consent tools frequently subscribe to user interactions and run measurable main-thread work on every click. The work is most often outside the engineering team's direct control, but the diagnostic surfaces which tag is running on which interaction path. The fix sometimes ships at the tag-manager configuration layer rather than the application code layer.
Event-handler discipline is the third surface. Handlers that recompute layout (forcing synchronous reflow), query the DOM repeatedly, or perform synchronous network calls produce predictable INP failures. The fix patterns include scheduling expensive work with requestIdleCallback or setTimeout to break the main-thread blocking, deferring non-critical updates with the View Transitions API, and moving computation off the main thread with Web Workers where the workload justifies the architectural cost.
The Page Experience signal layer in full, including the ranking-weight notes.
The composite pass condition and the visual-stability metric inside the score.
How the INP diagnostic integrates into the broader organic SEO program.
What operators ask about Interaction to Next Paint before the engineering work starts.
- 01.When did INP replace FID?
- Interaction to Next Paint replaced First Input Delay as the responsiveness Core Web Vital on March 12, 2024. The transition had been signaled through 2023 with INP available as an experimental metric in the web-vitals library and PageSpeed Insights. The March 2024 cutover removed FID from the composite Core Web Vitals score and made INP the responsiveness Vital evaluated inside the Page Experience signal.
- 02.What thresholds count as good, needs-improvement, and poor?
- Interaction to Next Paint at 200 milliseconds or under sits in good. Between 200 and 500 milliseconds is needs-improvement. Above 500 milliseconds is poor. The thresholds apply at the 75th percentile of field data through the Chrome User Experience Report, so the URL must hold at or under 200 milliseconds for three quarters of real-user sessions to clear the bucket.
- 03.Why did INP replace FID?
- First Input Delay measured only the latency of the first interaction on the page. The measurement was a delay rather than the full interaction-to-paint cycle. Pages whose first interaction happened to be fast scored well even when subsequent interactions ran slowly. INP measures the slowest interaction-to-paint latency across the entire page session, returning the worst experience the user actually had. The change exposes main-thread blocking that sustained interaction surfaces and that FID's first-interaction sampling missed.
- 04.What patterns produce a failing INP?
- Three patterns recur. First, JavaScript bundle size on the interaction paths: large synchronous bundles block the main thread when the interaction fires the handler. Second, third-party tag latency: analytics, advertising, and tag-management scripts running on the interaction paths add main-thread time outside the engineering team's direct control. Third, event-handler complexity: handlers that recompute layout, query the DOM repeatedly, or perform synchronous network calls. The web-vitals library exposes the slowest interactions per page session so the engineering team can target the specific interaction failing.
If you want INP handled as a load-bearing technical layer rather than a Lighthouse number, see how we work.
Two-week diagnostic. The INP work sits inside the broader technical foundation, alongside rendering parity, crawl budget, and the schema architecture that carries the entity signal.