Interaction to Next Paint (INP) measures the delay between a tap, click, or keypress and the next time the browser paints a frame. Google's good threshold is 200 milliseconds or less at the 75th percentile of visits. Above 500 milliseconds the page is poor. Shoppers do not wait for a button to acknowledge them, and the ranking systems that still use page experience can see the same delay you feel.
First Input Delay only timed the first interaction. INP watches interactions across the whole visit, so a fast homepage and a frozen checkout both show up. That is why sites that "passed Core Web Vitals" in 2023 fail them now.
Where the time actually goes
INP is not a single slow image. It is usually one of these:
- A long JavaScript task on the main thread while the user taps "Add to cart."
- A third-party chat, tag manager, or A/B tool that runs during the click.
- A hydration step that attaches listeners only after a large bundle downloads.
- Layout work that runs because a banner injects itself above the button.
Direct answer: If INP is over 200 ms, find the long task that runs on click, split it, and stop non-critical scripts from executing on the interaction path. The metric moves when the main thread is free at the moment of the tap.
Thresholds you can hand to a developer
| INP at the 75th percentile | Rating | What to do this sprint |
|---|---|---|
| 200 ms or less | Good | Keep the interaction path free of new tags |
| 201–500 ms | Needs improvement | Profile the click in Chrome Performance and cut the longest task |
| Over 500 ms | Poor | Remove or defer the script that runs inside the event handler |
LCP (loading) and CLS (layout shift) still matter. They do not excuse a button that paints late. Treat INP as its own ticket, with its own owner.
A checkout we measured
On a mid-size store, the product page loaded in under two seconds and still lost the add-to-cart tap. The performance trace showed a 640 ms task from a personalization script that rewrote the price on every click. INP at the 75th percentile was 580 ms on mobile. After the script was moved off the click handler and the price was rendered with the page, INP fell under 180 ms and the add-to-cart rate recovered in the next full week of traffic.
You do not need that anecdote to start. Scan the URL and read the performance issues before you buy another tag. The same audit flags the SEO and accessibility problems that sit next to a slow handler. How those pages get cited once they are fast is covered in why answer engines skip your site.
The fix order that works
- Record one real mobile tap in Chrome DevTools, Performance panel, with CPU throttling on.
- Find the long task whose start sits inside the click event.
- Move analytics, chat, and experiments off that handler. They can run after the paint.
- Break remaining work into tasks under 50 ms so the browser can paint between them.
- Re-test the 75th percentile on field data, not a single lab run from your office connection.
Lab data lies when the office network is fast and the customer's phone is not. Field INP is the number that matches revenue.
What this is worth
A late paint is a broken button from the customer's side of the glass. They tap twice, the second tap hits the wrong control, and they leave. That shows up as a conversion drop long before it shows up as a ranking drop.
If the scan turns up a pile of handlers you do not own, the scanner lists which third parties run during input so you can remove them with evidence. For a template that is slow on every page, start with the team and send the URL through contact.
