What Is Interaction to Next Paint (INP)?

How Interaction to Next Paint Works

Interaction to Next Paint measures responsiveness — the lag between doing something on a page and seeing the page react. Every time a user clicks, taps, or presses a key, the browser has to run the associated event handlers and then paint an updated frame. INP watches all of those interactions during a visit and records how long each took, from the input to the next visible paint. It then reports, roughly, the single longest one, so the score reflects the worst friction a user actually hit rather than a flattering average.

That “worst interaction” design is the point. A page might handle 40 taps beautifully and one terribly; the one bad tap is what a user remembers, and it’s what INP surfaces. Measurement happens on real Chrome users through the Chrome UX Report, and like every Core Web Vital the reported value is the 75th percentile — the number three-quarters of visits stay under.

The metric is deliberately narrow about what counts as an interaction. Clicks, taps, and keypresses qualify. Scrolling, hovering, and pinch-zoom do not, because they are handled by the browser’s compositor rather than by JavaScript event handlers on the main thread, and INP is designed to catch main-thread work that blocks a visible response.

The Three Components of an Interaction

Every interaction INP measures splits into three consecutive parts. Each is a place responsiveness can go wrong:

• Input delay — the time from the user’s action until the event handler can begin running. Long tasks already occupying the main thread are the usual cause. This is the only part First Input Delay ever measured.
• Processing duration — how long the event handlers themselves take to execute. Heavy or poorly-written handlers stretch this out.
• Presentation delay — the time from when the handlers finish until the browser paints the next frame showing the result. A large, complex DOM or expensive layout work inflates this.

Add the three and you have the interaction’s total latency. INP’s good threshold of 200 milliseconds is the budget for all three combined, on the slowest interaction of the visit.

Example of Interaction to Next Paint

The defining event for this metric is its promotion to a Core Web Vital on March 12, 2024, replacing First Input Delay — and the reason for the swap is the clearest worked example of what INP captures that FID missed.

The timeline is documented: Chrome shipped INP as an experimental metric in May 2022, announced in May 2023 that it would become a Core Web Vital in March 2024, promoted it on schedule on March 12, 2024, and deprecated FID across its tools and APIs on September 9, 2024. First Input Delay measured only the input delay of the first interaction. That is a tiny slice — it excluded the event processing, excluded the paint, and ignored every interaction after the first. As a result the web’s FID scores were overwhelmingly “good,” which made the metric almost useless as a signal: it rarely told anyone their page was actually sluggish.

INP measures the full latency of every interaction. When Chrome ran the two metrics side by side across the real web, sites that passed FID comfortably frequently landed in INP’s needs-improvement or poor bands, because their heavy JavaScript stretched processing and presentation on interactions FID never looked at — the search filters, the “load more” buttons, the mega-menus deep in a session. Nothing about those pages had changed; the measurement finally caught friction that was always there.

The lesson is that INP rewards architecture, not tricks. Because it captures input delay, processing, and presentation across the whole visit, the durable fixes are structural: break long tasks into smaller ones, defer non-critical scripts, yield the main thread so the browser can paint, and keep the DOM small enough that response frames render fast. There is no way to game a metric that reports your worst real interaction — you have to make the interactions genuinely fast.

Interaction to Next Paint and the Other Core Web Vitals

INP is the responsiveness leg of Core Web Vitals, sitting alongside Largest Contentful Paint for loading and Cumulative Layout Shift for stability. The three often share a root cause: the same excess JavaScript that delays LCP by blocking rendering also occupies the main thread and inflates INP’s input delay. That overlap is good news for prioritization — trimming and deferring JavaScript, the single highest-leverage performance move, tends to improve loading and responsiveness together. INP is simply the metric that makes main-thread bloat impossible to hide behind a fast first paint.

Frequently Asked Questions

The Bottom Line

Interaction to Next Paint grades how snappy a page feels when you actually use it — tapping a button, opening a menu, typing in a field — by timing how long until the screen visibly responds. Keep the slowest interaction under 200 milliseconds for most users and the page reads as responsive. It is the strictest, most complete responsiveness metric Google has shipped, which is why it retired First Input Delay.