Interaction to Next Paint replaced First Input Delay as a Core Web Vital on 12 March 2024. A site that passed FID comfortably can fail INP badly. What did FID measure, what does INP measure, and why does the change match user complaints better?

The mechanism

FID measured the delay before the first interaction's handler began to run, and nothing else. Two consequences follow, and both flatter the site:

• Only the first interaction counted. If the first click was on a page that had finished loading, it was fast, and every slow interaction afterwards was invisible to the metric.
• Only the waiting counted, not the work. FID stopped its clock when the event handler started. A handler that then ran for 900 ms and re-rendered half the page produced a good FID and an unusable page.

INP measures the whole interaction and reports one of the slowest over the page's lifetime: the delay before the handler runs, the handler's own processing, and the time until the browser paints the next frame. That last part is the one teams find surprising — a fast handler that triggers an expensive re-render still produces a bad INP, correctly, because the user is looking at a stale screen until the paint happens.

Why it matches complaints

Users do not complain about the first click. They complain that the third filter takes a moment, the dropdown lags, typing feels behind. Those are later interactions with real work behind them, which is precisely the set FID excluded. A site could pass FID at p75 while every meaningful interaction was slow, and many did, which is why the metric was replaced rather than adjusted.

The thresholds are worth remembering: 200 ms or less is good and above 500 ms is poor, at the 75^th percentile of a page's interactions. The old FID threshold of 100 ms measured a different and much smaller quantity, so the two numbers cannot be compared.

What to do about it

The diagnosis follows the three parts of the measurement, because each has a different fix:

1. Input delay means the main thread was busy when the user acted — usually a long task from hydration, a third-party script, or your own initialisation. Break long tasks up and yield to the browser between chunks.
2. Processing time means the handler is doing too much. Do the minimum needed to update what the user sees, and defer the rest to after the next paint.
3. Presentation delay means rendering is expensive: a large component tree re-rendering, layout thrash from reading and writing style in a loop, or a synchronous re-render of a list with thousands of rows.

When this is not the metric to chase

If your INP is 180 ms at p75 and users are complaining, the problem is somewhere else — a slow API, a confusing flow, or a loading experience that the responsiveness metric does not capture. And on a genuinely static page with no interactions, INP has nothing to measure and the loading metric is your target. Choose the metric from the complaint: "slow to appear" is the loading metric, "slow to respond" is INP, "jumps around while I read it" is layout stability.

Common weak answers

• "We pass in the lab, so we are fine." A lab run cannot measure INP properly, because it depends on which interactions real users perform. Field data is the only source of truth here, and a lab test can only reproduce a specific interaction you already suspect.
• "Our p50 is fine." These metrics are defined at p75 for a reason: the tail is where the devices and networks that hurt live, and a p50 taken from fast devices hides it entirely.
• "Add a loading spinner." A spinner acknowledges the delay. It does not reduce it, and it does not change the metric, because the paint the user is waiting for is still late.