Interaction to next paint (INP)
What is interaction to next paint (INP)?
Interaction to next paint (INP) measures how quickly a page visibly responds to a click, a tap or a key press. The browser times the interactions throughout a visit and reports one of the slowest: 200 milliseconds or less is good, above 500 is poor. INP replaced the older FID as a Core Web Vital in March 2024, and PageSpeed Insights shows it only in the real-visitor data, because a lab test does not click anything.
Example
On a sports-goods shop, a customer taps the “In stock only” filter on a category page, and the page only changes 450 milliseconds later. The delay has three parts:
- 80 ms — the browser is busy running a chat widget’s code and cannot take the tap yet;
- 250 ms — the filter redraws all 400 products at once;
- 120 ms — painting the new screen.
450 ms sits in the middle band, between 200 and 500. Loading the chat only when someone first touches its icon cuts the wait before the tap is handled to 20 ms. Showing the first 24 products and the rest on scroll brings processing down to 90 ms, and with less to draw, painting takes 50 ms. The new total is 20 + 90 + 50 = 160 ms, inside the good band.
Why it matters for a business
Poor INP feels like a site that is not listening. “Add to basket” does nothing, so the customer taps again and ends up ordering two, or decides the shop is broken. The cause is almost never the hosting. It is the code running in the browser: heavy themes, plugins and third-party scripts piled up over the years, nearly all of it JavaScript. INP gets worse quietly, with each new add-on, which is why we keep watching it after the fix.
How to improve it
- Less JavaScript at load: anything not needed straight away is deferred.
- Chat, video and maps load on first use, not when the page opens.
- Long tasks in the code are broken up so the browser can answer a click in between.
- Pages with a lot on them, such as categories, tables and configurators, render in parts.
A lab test does not click, so INP shows up in real-visitor data, and in lab runs we track its stand-in, total blocking time. This work on the code is part of our website speed optimisation.