For years, Core Web Vitals measured responsiveness with First Input Delay. FID had a comfortable problem: almost everybody passed it. A page could freeze for half a second every time you tapped a menu and still score green, because FID only measured the first interaction — and only its input delay, not the work that followed.
That’s why Google replaced it with Interaction to Next Paint (INP). If your dashboards suddenly turned orange, this is what changed.
What INP actually measures
INP looks at (almost) every click, tap and keypress during the whole visit, measures how long it takes from the interaction until the next frame is painted, and reports one of the worst cases. Three phases count:
- Input delay — the main thread was busy when the user interacted.
- Processing time — your event handlers doing their work.
- Presentation delay — layout, paint and compositing before the user sees a response.
The thresholds: under 200 ms is good, over 500 ms is poor. And unlike FID, you can’t pass by having a fast first click and a janky everything-else.
Where pages lose the budget
In practice most bad INP comes from a handful of patterns: long tasks triggered by handlers (rendering a huge list synchronously after a click), layout thrashing (reading offsetHeight in a loop that also writes styles), and third-party scripts attaching heavy listeners to everything.
Quick wins
- Break long tasks up —
scheduler.yield()where available,setTimeoutchunking where not. - Give the browser a frame: update the UI optimistically first, do the heavy work after.
- Use CSS
content-visibilityso off-screen updates don’t cost paint time. - Audit third parties — a tag manager firing on every click is an INP tax on your whole site.
The deeper lesson is the same one this blog has always pushed: the browser has a budget, and everything you ship spends it. INP just finally measures the spending where users feel it most — when they’re trying to interact.