Interaction to Next Paint

A site passes every responsiveness check and users say the interface lags. The explanation is usually that the old metric measured almost none of what the user experiences. First Input Delay timed the gap before the first interaction's handler began, and stopped there. Two things were therefore invisible: every interaction after the first, and all of the work the handler and the renderer actually did.

Interaction to Next Paint measures the whole thing. For each interaction it counts the input delay, the time the event handlers run, and the presentation delay until the browser paints the resulting frame; the page's INP is one of the slowest of those, reported from real sessions. Good is 200 ms or less at the 75^th percentile and poor is above 500 ms. The old FID threshold of 100 ms measured a much smaller quantity, so the two numbers are not comparable and a site can go from comfortably passing to clearly failing without changing a line of code.

Why it matters

It is the first widely adopted metric that matches the complaint people actually make. Nobody reports that the first click was slow; they report that the third filter takes a moment, that the dropdown lags, that typing feels behind. Those are later interactions with real work behind them, precisely the set the previous metric excluded.

It also changes where optimisation effort goes. A loading-focused metric rewards shipping less on first paint, which teams achieved by deferring work into the interactions. INP prices that deferral, so a page that paints in 1.2 seconds and then takes 600 ms to respond to a click no longer looks fast.

Implementation patterns

• Collect it from the field, per route, at p75. A lab tool cannot measure it properly because it depends on which interactions real users perform; synthetic runs can only reproduce an interaction you already suspect.
• Attribute it to the three parts, because each has a different fix. Input delay means the main thread was blocked, usually by hydration, a third-party script or your own initialisation. Processing means the handler does too much. Presentation delay means rendering is expensive — a large tree re-rendering, layout thrash, or a long list rendered synchronously.
• Break long tasks and yield to the browser between chunks, so an interaction arriving mid-task waits milliseconds rather than hundreds of them.
• Do the visible work first and defer the rest past the next paint. Update the control the user touched, paint, then fetch and reconcile.
• Report which element and which interaction type produced the worst values, since the metric without attribution tells you that something is slow and not what.
• Segment by device class. A p75 dominated by desktop sessions hides the phones where the work is three to five times slower.

Industry example

The change is documented by the Chrome team on web.dev: INP was introduced as an experimental metric in 2022, announced as the future Core Web Vital in 2023, and became one on 12 March 2024, replacing FID. The stated reason is the one above — FID captured only the first input's delay and so reported passing scores for pages whose later interactions were poor.

The practical consequence showed up across the industry in the months around the change, as teams that had passed on responsiveness for years found themselves failing and traced it to handlers and re-renders that no previous metric had priced.

Failure scenarios

• Passing in the lab and failing in the field, because the lab exercises one interaction on a fast machine.
• A p50 that looks healthy while the p75 fails, since slow devices and cold caches live in the tail and these metrics are defined at p75 for that reason.
• A spinner treated as a fix. Feedback is good practice and does not shorten the wait or improve the metric, because the paint the user is waiting for is still late.
• Optimising the wrong third. Teams commonly attack input delay when their problem is presentation delay, and spend a quarter on code splitting that cannot help.
• Regression from a component library upgrade, where a context change makes a large subtree re-render on every keystroke, visible only as a field metric shift.

Trade-offs

When not to use it

On a page with no interactions, INP has nothing to measure, and the loading metric is the target. If your INP is 180 ms at p75 and users are still complaining, the cause is elsewhere: a slow API, a confusing flow, or a loading experience the responsiveness metric does not capture. Choose the metric from the complaint — "slow to appear" is the loading metric, "slow to respond" is INP, "jumps while I read it" is layout stability — and resist the common mistake of running a whole performance programme against whichever number is currently red.

Interview question

Q: Your site passed FID at p75 for two years and now fails INP badly. Explain why that can happen with no change to the code, and tell me how you would find the cause.

What a strong answer covers: the definitional difference — first interaction versus one of the slowest, and delay-only versus delay plus processing plus paint — and that the thresholds are not comparable; that the diagnosis needs field data with attribution to element, interaction type and phase; mapping each phase to its class of fix; segmenting by device class; and knowing that a lab measurement cannot substitute here.

Quick check

Quiz: Which three intervals make up an INP measurement? Input delay before the handler runs, the handlers' processing time, and the presentation delay until the next paint.

Flashcard: What was FID's structural blind spot? — It measured only the first interaction and stopped timing when the handler began, so later interactions and all handler and render work were invisible.