TL;DR
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. It measures how long the page takes to respond to every click, tap and key press during a visit, not just the first one. Google marks 200 milliseconds or less as good at the 75th percentile, and anything above 500 milliseconds as poor.
What actually changed
First Input Delay measured one thing: the gap between a visitor's first tap and the moment the browser could start handling it. A page could score well on that number and still feel sluggish for the rest of the visit.
Interaction to Next Paint measures the delay before the browser paints the next frame after an interaction, across the whole session. It records the slowest interactions and reports a high percentile rather than a single sample. A page with one heavy screen or one badly written dropdown now carries that cost in its score.
Why so many sites fail it
The common cause is not a slow server. It is the main thread being busy when the visitor interacts. Long JavaScript tasks, large bundles parsed during load, third party tags that fire on idle, and components that re-render the whole page for a small change all push the response past the threshold.
Mobile hardware makes it worse because the same script takes longer to run on a mid range phone than on a laptop. A site that feels instant on a developer machine can sit in the warning band on a three year old Android device.
What usually drags the number down
- Long tasks over 50 milliseconds in the main thread, especially during load
- Hydration or framework startup that runs while the visitor is already tapping
- Third party scripts for chat, heatmaps and advertising loaded before the page settles
- Event handlers that do heavy work on every keystroke rather than on a debounce
- Layout shifts triggered inside a click handler, which force a second paint
How we locate the slow interaction
Start with field data. Search Console and the Chrome UX Report show the real distribution across visitors and devices. That tells you whether the problem is broad or limited to one template.
Then reproduce it in the lab. Record a performance trace while interacting with the specific page, and look at the longest tasks between the input and the next paint. The trace names the function that ran too long, which is the only detail that leads to a real fix.
What to fix first
Break up the long tasks before chasing smaller wins. Defer non critical scripts, split bundles so a page does not parse code it never uses, and move expensive work out of the event handler. If a component re-renders an entire list for one row change, fix that before touching images.
Images and fonts still matter, but they mostly affect loading metrics. INP is about what happens after the visitor starts using the page, so the work is in JavaScript and rendering, not in the asset pipeline.