On 12 March 2024, Interaction to Next Paint replaced First Input Delay as a Core Web Vital. Google had announced it a year in advance and plenty of teams still discovered it the way you discover a pothole. Scores that had been green for two years went amber, nobody had shipped anything, and the report was correct.
The reason is that the two metrics measure genuinely different things, and FID was measuring the easy half.
What changed
FID measured input delay only. A user taps, and FID records how long the browser waited before it could begin running the handler. It stopped counting there. It did not care what the handler then did, how long that took, or whether anything visibly changed on screen. It also only ever measured the first interaction of a page visit.
INP measures the whole round trip, from the interaction to the next frame the browser paints in response, and it does that across every interaction in the visit rather than the first one. It then reports roughly the worst of them.
That is why sites passed FID and fail INP. A page could accept your click instantly and then spend 600ms doing work before anything moved, and FID would call that a good experience. It felt terrible and scored well.
- INP good200ms
- INP needs work200–500ms
- INP poorover 500ms
web.dev, current Core Web Vitals documentation. Thresholds are assessed at the 75th percentile of real user visits, so passing means three quarters of visits are under the bar, not the average.
The Core Web Vitals thresholds, as Google publishes them. INP good: 200ms. INP needs work: 200–500ms. INP poor: over 500ms.
The 75th percentile trap
This detail catches people repeatedly. Core Web Vitals are assessed at the 75th percentile of real visits, not the mean. A comfortable average tells you nothing, because averages are dominated by your fastest users on fast machines.
The practical consequence is that a site can look fine to everyone in the building and fail in the field. The office has good hardware, good connectivity, and a warm cache. The 75th percentile visit is a mid-range Android phone on congested mobile data, and that visit is what Google scores you on.
- 2.5sLCP: largest contentful paint, good threshold
- 200msINP: interaction to next paint, good threshold
- 0.1CLS: cumulative layout shift, good threshold
- 75thPercentile at which all three are judged
web.dev. All assessed at the 75th percentile of real user visits.
What causes bad INP
INP is almost always a main thread problem. The browser has one thread for running your JavaScript and painting the page, and it cannot do both at once. Anything that occupies that thread for a long stretch delays the paint that INP is timing.
The usual suspects, roughly in order of how often they turn out to be the answer:
- 01Third-party tags. Tag managers, chat widgets, session recorders and A/B testing scripts, all competing for the same thread
- 02Long tasks in your own handlers. Work that could be deferred, batched, or done after the paint
- 03Oversized hydration. Shipping a component tree that re-renders on interaction when static HTML would have done
- 04Layout thrash. Reading and writing DOM geometry in a loop, forcing repeated synchronous layout
The third-party point deserves emphasis because it is the one with an uncomfortable business answer. Every tag you add competes for the thread that INP measures. An A/B testing script that blocks rendering to avoid a flicker is directly trading your INP score for a cleaner test. A session recorder capturing every DOM mutation is doing real work on every interaction.
We have a stake in that argument, so it is worth stating the bias plainly. This is the reasoning behind keeping our own tracker under 5KB with zero dependencies, and it would be convenient for us if you concluded that every other tag on your site is the problem. Measure it rather than taking our word for it.
How to measure it honestly
Lab tools like Lighthouse cannot really measure INP, because INP needs a human interacting over a real visit and Lighthouse runs a scripted load. A Lighthouse run will give you a proxy and a set of diagnostics worth reading, and it will not give you your actual score.
Field data is the answer, and Google gives it away. The Chrome User Experience Report contains real 75th percentile Core Web Vitals for any site with enough traffic, it is free, and it is the same data Google uses. PageSpeed Insights shows it at the top of the report, above the lab results most people scroll straight to.
One caution on the business case. INP is a ranking signal, and the evidence that ranking signals of this type move rankings much is thin. The better argument is the direct one. Interactions that feel slow lose people, and for paid traffic every one of those people arrived on an invoice. Our piece on the three second cliff has the bounce probability curve behind that claim, and the five speed statistics everyone quotes checks the provenance of the numbers you will hear in this conversation.