Interaction to Next Paint (INP) is a measure of how quickly a web page shows a visible response after someone clicks, taps or types on it. It is one of Google’s three Core Web Vitals, and it replaced First Input Delay in March 2024.
How INP works
Every time a visitor interacts with a page, for example opening a menu, ticking a filter or tapping “Add to basket”, the browser has to run any code attached to that action and then redraw the screen. INP times the gap between the interaction and the next frame the browser paints. That gap has three parts:
- Input delay: the wait before the browser can even start handling the action, usually because it is busy with other scripts.
- Processing time: how long the code attached to the action takes to run.
- Presentation delay: the time to recalculate the layout and paint the result.
The browser records interactions throughout the visit and reports close to the slowest one, ignoring a small number of extreme outliers on busy pages. Scrolling and hovering are not counted. Google’s thresholds are 200 milliseconds or less for “good”, up to 500 milliseconds for “needs improvement”, and anything slower as “poor”, judged on the 75th percentile of real visits.
Because INP depends on real people doing real things, it is a field data metric. The scores in Search Console and PageSpeed Insights come from the Chrome UX Report, which collects anonymous measurements from Chrome users. A standard page-load test such as Lighthouse cannot measure INP, because nobody clicks anything during it; it reports Total Blocking Time as a rough stand-in.
Why it matters
A slow response feels broken. Someone taps “Book now” on a salon website, nothing happens for most of a second, so they tap again and end up with two bookings, or give up. On mobile, where most UK browsing happens on mid-range phones rather than the fast laptops sites are built on, the effect is far stronger than developers tend to see in testing.
Google uses Core Web Vitals as part of its page experience signals. Their weight in rankings is modest compared with relevance and quality, so fixing INP will not lift a weak page above a strong one. The stronger case is commercial: a responsive checkout, booking form or quote calculator loses fewer people at the point they were about to act.
Common mistakes
- Testing only on a fast desktop. The same page that responds instantly on a new laptop may take half a second on a three-year-old Android phone.
- Piling on third-party scripts. Chat widgets, heatmaps, review carousels and several ad pixels all compete for the browser’s main thread and add input delay.
- Doing heavy work on every click. Filters that re-render an entire product grid, or handlers that recalculate a whole page, inflate processing time.
- Chasing a Lighthouse score. A perfect lab score does not mean a good INP, because the lab test never interacts with the page.
- Ignoring the cookie banner. A consent tool that loads a large script bundle can slow the very first tap many UK visitors make.
How to act on it
Open the Core Web Vitals report in Search Console to see which groups of URLs fail on mobile, then check a representative page in PageSpeed Insights for its field INP. To find the slow interaction itself, record a session in Chrome DevTools’ Performance panel while clicking through the page, and look for long tasks after each action.
The usual fixes are to remove or defer scripts that are not earning their place, break long tasks into smaller pieces so the browser can respond in between, give instant visual feedback such as a pressed state or spinner before heavy work starts, and avoid rebuilding large parts of the page on each interaction. On WordPress sites, the culprits are often plugins that load everywhere when they are needed on one page.
Speed work sits inside a broader technical SEO review, because the fixes often touch themes, plugins and tracking at the same time, and they should be checked against conversion tracking before anything is removed.