Interaction to Next Paint (INP)

Interaction to Next Paint measures how quickly a page responds visually to user input, reporting a value representative of the worst interaction latencies experienced during a visit. It replaced First Input Delay as a Core Web Vitals responsiveness metric in March 2024, and the change was significant: where the older measure captured only the delay before processing began on the first interaction, this one measures the full duration from input through processing to the next frame being painted, across all interactions in the session.

That difference matters because the earlier metric flattered many sites. A page could register an excellent first input delay while remaining sluggish throughout, because the measure ignored how long the event handler took to run and how long the browser then took to render the result, and because it looked at only one interaction. Sites that appeared responsive under the old measure frequently do not under the new one, particularly single-page applications and any interface with heavy client-side logic.

The reported value is derived from the longest interactions observed, with an allowance for outliers on pages with many interactions, and Google's published threshold treats 200 milliseconds or less as good at the seventy-fifth percentile of real user experiences. Because it captures the whole path from input to paint, poor scores can originate at several points: long tasks on the main thread blocking the browser from handling the event, event handlers doing excessive work synchronously, layout thrashing caused by reading and writing styles in an interleaved way, and expensive rendering after state changes.

Diagnosis typically points to JavaScript execution rather than to network conditions, which distinguishes this metric from loading measures. Common causes include large monolithic bundles executing on the main thread, third-party scripts running arbitrary work during interaction, framework re-renders that touch far more of the tree than the change requires, and handlers performing synchronous computation that could be deferred or moved off the main thread. Long tasks are the underlying mechanism in most cases, since the browser cannot respond to input while a task is running.

Remediation follows the diagnosis. Breaking long tasks into smaller pieces with explicit yielding lets the browser handle input between them. Deferring non-essential work until after the visual update, so the user sees a response immediately, addresses the most common pattern. Reducing the amount of JavaScript shipped, auditing third-party scripts for main-thread cost, virtualizing long lists, and moving heavy computation to a worker each address specific causes. Providing immediate visual feedback for slow operations does not improve the measured value but does change how the delay is experienced.

Third-party scripts deserve specific scrutiny because they are a frequent cause and are outside the team's direct control. Chat widgets, consent managers, analytics libraries, personalization tools, and advertising scripts all execute on the main thread and can occupy it during precisely the moments a visitor is trying to interact. Auditing the main-thread cost of each third party, ideally by measuring the page with and without it, produces a concrete list of what each vendor costs in responsiveness terms. That figure makes the trade-off discussable with the teams that requested each tool, which is usually a more productive route than attempting to optimize application code around a script that is consuming most of the available budget.

Because the metric is driven by application code rather than by asset delivery, improving it usually requires engineering work rather than configuration. In practice it sits at the boundary between web performance and product development, and it is particularly consequential for interactive commerce and booking interfaces, where unresponsive filtering, configuration, and cart interactions produce abandonment that appears in analytics as ordinary drop-off with no obvious cause.