You tap a menu. Nothing happens. You tap it again, and now it opens and closes.
That is what the Failure Interaction to Next Paint measures. Not how fast the page arrived, which is a different metric, but whether it responds when somebody touches it.
It matters because it is the one visitors interpret as the site being broken rather than slow. A slow page is forgiven. A page that ignores you is not.
Interaction to Next Paint: Measure and Improve INP
What it actually measures
The delay between an interaction and the next visual update, across the whole visit rather than only the first interaction.
Every tap, click, and key press is measured. The reported figure is close to the worst of them, which means one badly handled interaction can define your score even if everything else responds instantly.
Good is under 200 milliseconds. Poor is over 500. These are assessed on real visits at the 75th percentile, so they describe a poor-conditions experience rather than an average one.
Why pages stop responding
The browser does one thing at a time on the main thread. While JavaScript is running there, nothing else happens, including responding to input.
So a long task blocks the response. The visitor taps, the browser notes it, and cannot act until the current work finishes.
Four common causes:
- Large scripts executing on load, particularly frameworks initialising.
- Third-party scripts, which run at times you do not control and are frequently the largest single contributor.
- Expensive event handlers doing substantial work in response to a click rather than deferring it.
- Layout thrashing, where code repeatedly reads and writes layout properties and forces the browser to recalculate.
Why phones suffer most
The same JavaScript takes considerably longer to execute on a mid-range phone than on a development laptop.
This is why INP is the metric most likely to look fine in testing and fail in the field. A developer with a fast machine on a fast connection will rarely reproduce it, and a lab score will not surface it either.
Test on a real mid-range device, and trust field data over anything simulated.
Improving it
- Ship less JavaScript. The most direct fix and the hardest. Audit dependencies and prefer browser-native solutions where they will do.
- Break up long tasks. Splitting work so the browser can respond between chunks turns one blocking task into several interruptible ones.
- Defer what is not needed immediately. Analytics, chat widgets and non-critical features do not need to initialise before the page is usable.
- Audit third parties hard. These are frequently the largest contributors and the easiest to remove, since many belong to tools nobody uses.
- Keep handlers light. Do the minimum needed to give visual feedback, then do the rest afterwards. A button that acknowledges the press immediately feels responsive even when the underlying work takes longer.
The web.dev guidance on INP covers diagnosis and the current thresholds in detail.
Acknowledge the input even when the work is slow
Some operations genuinely take time. A search returning results, a filter recalculating, a payment being authorised.
The mistake is doing all of that work before showing anything. From the visitor’s side, a button that does nothing for two seconds is indistinguishable from a button that is broken, and their response is to press it again.
Give immediate visual feedback instead. The button changes state, a spinner appears, the field shows it has been accepted. Then do the substantial work. The total time is identical and the experience is entirely different, because the person now knows their action registered.
This also prevents duplicate submissions, which are a common consequence of unresponsive controls and cause real problems on forms and checkouts.
Measuring it honestly
Field data in Search Console or PageSpeed Insights is the authoritative source, since it reflects real interactions on real devices.
Lab tools can simulate interactions but cannot reproduce the variety of real usage, so treat a good lab result as unproven rather than confirmed.
Where performance and environmental impact both apply, treat them as the same lever: reducing unnecessary data transfer and processing supports a faster experience while lowering estimated digital carbon, though environmental figures remain modelled rather than directly measured. Less JavaScript improves both, since execution is where device energy is spent.
Our sustainable web development work uses field data as the starting point, because INP is the metric lab testing hides.