What is Interaction to Next Paint (INP)?
INP measures responsiveness. Every time a visitor interacts with a page (a tap, a click, a key press), the browser has to run whatever code is attached to that action and then paint the result on screen. INP is the time from the interaction to that next paint, and a page's score is roughly the worst such delay a typical visitor experiences across their whole visit, ignoring a few outliers on pages with many interactions. Google rates 200 milliseconds or less as good, up to 500 as needing improvement, and anything slower as poor.
It replaced First Input Delay as the responsiveness measure in Core Web Vitals in March 2024. FID measured only the first interaction and only the delay before the browser started handling it; INP measures every interaction and the full time until the user sees a response, which is much closer to what feels slow.
Why it matters
Why INP matters
Because a page that loads fast and then stalls when you touch it feels broken. A menu that opens half a second after the tap, a filter that freezes the product grid, a form field that lags behind typing: these are the moments visitors blame the brand for, and they happen after the page has passed every loading test. INP is the first widely used metric to catch them, and since it is part of Core Web Vitals it feeds Google's page experience signals and therefore rankings.
It is also the metric most likely to be hurt by the things a marketing site accumulates: tag managers, chat widgets, consent tools, analytics, personalization scripts and animation libraries, each of which can block the main thread at the moment a user wants a response.
In practice
How INP works in practice
- 01
The field data comes from real visitors through the Chrome User Experience Report, and it is what Google uses. PageSpeed Insights and Search Console's Core Web Vitals report show whether a site passes, and which page groups fail. Lab tools such as Lighthouse and the Chrome DevTools performance panel then find the cause: long tasks on the main thread, heavy event handlers, layout work triggered by a click, or third-party scripts running at the wrong time.
- 02
Fixes are mostly about keeping the main thread free. Break long JavaScript tasks into smaller ones, defer work that is not needed for the immediate response, give the user an instant visual acknowledgment (a pressed state, a spinner) before the heavy work runs, reduce the amount of DOM a click has to touch, and audit every third-party script for what it does on interaction. On many sites the single biggest improvement is removing a tag that nobody remembers adding.
Watch out
What people get wrong about INP
Testing it in the lab only. Lighthouse runs a page without touching it, so it cannot measure INP directly; the real number comes from field data, and a page can score well in a lab and poorly for actual visitors on actual phones. The other mistake is assuming a fast load means a responsive page; the two are separate, and a site optimized hard for Largest Contentful Paint can still have a dreadful INP. The third is ignoring the long tail: INP reports a near-worst interaction, so one slow element on a page drags the whole score down even if everything else is instant.
