Interaction to Next Paint
INP / responsiveness / input delay / slow interaction
Interaction to Next Paint measures how long a page takes to respond visibly to a click, tap or key press. It reports the worst interaction of the visit rather than the average, ignoring outliers, and it breaks into three parts: input delay, processing duration and presentation delay.
The unusual thing about this measurement is which number it reports. web.dev describes INP as assessing a page's overall responsiveness by observing the latency of all click, tap and keyboard interactions across a visit, and then says the final value is the longest interaction observed, ignoring outliers. Not the average. The worst one.
That single design choice explains most of the confusion around it. A site where ninety-nine interactions are instant and one takes two seconds does not score well, because the one is what gets reported. web.dev is careful here: for most sites the interaction with the worst latency is reported, but on pages with very many interactions, random hiccups are discounted so a single unlucky moment does not define an otherwise responsive page.
Like the loading metric, it decomposes. Input delay is the time before any callback for the interaction is handled. Processing duration is the time for all the callbacks to execute. Presentation delay is the time after the callbacks finish until the frame actually appears on screen. Three places a slow response can live, and they call for different fixes.
Two more details change how you read a report. web.dev says the page's INP is calculated when the user leaves the page, so the figure depends on how much the visitor actually did. And Mozilla explains why this replaced the older metric: First Input Delay measured only the first interaction, and only the delay part, while INP considers every interaction and the whole span through to the next frame being painted.
In practice
This is the measurement that contradicts the room. Everyone at the business clicks around the site, agrees it feels fast, and the report disagrees. Both are right. The team is describing the typical interaction and the metric is describing the worst one, which is often a single menu, filter or form control that nobody in the room happens to use.
Not the same as
- Largest Contentful Paint
- That is about loading the page. This is about what happens after somebody touches it.
- An average response time
- It is explicitly the longest interaction of the visit, with outliers discounted.
Why it matters to you
Because it reports a worst case, it is the one measurement where a single bad component can fail an otherwise good site, and equally where fixing one thing can move the whole number. That makes it unusually worth diagnosing before spending. The question is not how to make the site faster in general. It is which interaction is the slow one, and which of the three parts it sits in.
What to ask or check
- 01Which specific interaction is producing our INP, and on which page?
- 02Is the time in input delay, processing, or presentation, since the fixes differ?
- 03Does our testing involve a real person using the slow control, rather than loading the page?
What people get wrong
That it describes how the site generally feels. It reports the longest interaction observed during a visit, with outliers discounted, so the typical experience and the reported number can disagree honestly.
Red flags
- Performance work quoted without anyone naming which interaction is slow.
- A score dismissed because the team finds the site responsive, which measures a different thing.
- Testing that only loads pages, since a metric about interaction needs an interaction.
Where you will see it
In the Core Web Vitals report in Search Console and in PageSpeed Insights field data, where it is reported from real visits rather than a simulation.