Interaction to Next Paint punishes the thing your users actually notice: the pause between tapping something and seeing it respond. Field data shows the busiest sites on the web fail it most. Here is what causes it and the order to fix it in.
Of the three Core Web Vitals, Interaction to Next Paint is the one that maps most directly onto how a site feels. Largest Contentful Paint measures how quickly something appears. Cumulative Layout Shift measures whether it stays put. INP measures the pause between a user tapping something and the screen acknowledging it — the half-second of nothing that makes people tap again, then a third time, then leave.
It is also the one most sites fail, and the pattern in the field data is the opposite of what people expect.
What INP actually measures
INP observes every click, tap and key press during a page visit and reports a figure close to the worst of them — not the average. One catastrophic interaction can define the page, which is deliberate: users remember the interaction that hung, not the fifty that did not.
The threshold for good is 200 milliseconds or less, assessed at the 75th percentile of visits, with mobile and desktop measured separately. That percentile matters. You do not need every interaction to be fast; you need three quarters of your real users to be having a fast experience, on the devices and networks they actually have.
Each interaction breaks into three parts, and knowing which one is slow tells you what to fix.
- Input delay — the gap before your handler runs at all, usually because the main thread is busy with something else.
- Processing time — your event handler doing its work.
- Presentation delay — everything between the handler finishing and the next frame painting: style recalculation, layout, paint.
Teams overwhelmingly assume the middle one is the problem. In practice, input delay and presentation delay dominate.
The counterintuitive part: popularity makes it worse
Field data from the Chrome UX Report in May 2026, covering 11.1 million origins, shows the split clearly. On mobile, 64.7% of the top 1,000 sites pass all three Core Web Vitals, against 39.2% of sites beyond the top million — the ranking you would expect.
Break it down by metric and it inverts. On INP specifically, the top 1,000 sites manage 72.5% good on mobile, while the long tail of the web manages 84.0%. The busiest sites on the internet load faster and respond worse.
The reason is not mysterious. Popularity buys a CDN, image optimisation and server capacity, all of which improve LCP. It also buys analytics, tag managers, personalisation, consent tooling, A/B testing, chat widgets and a large client-side framework — all of which run JavaScript on the main thread, which is the only place INP is decided.
Diagnose with field data, then reproduce in the lab
The order matters, and getting it backwards is the most common wasted week in performance work.
Start in the field. Lighthouse cannot measure INP, because INP requires a real person interacting with a real page. Use Search Console's Core Web Vitals report to find the URL groups failing, and CrUX or your own real-user monitoring to see which. If you have no RUM, add the web-vitals library with attribution enabled — it will tell you which element was interacted with and which phase was slow, which turns a vague complaint into a line of code.
Then reproduce in the lab. Open the page in Chrome DevTools, throttle the CPU to 4x or 6x slowdown — this is the single most important step, because your laptop is not your user's phone — record a performance trace, and click the thing your field data blamed. Long tasks show as blocks on the main thread. The one sitting between your click and the next frame is your answer.
The fixes, in the order they pay
1. Remove or defer third-party scripts. Every audit finds tags nobody can name, loaded on every page, for a campaign that ended two years ago. Removing a script is instant, free and permanent, and no amount of clever code-splitting beats it. What remains should load after interaction wherever the vendor allows it.
2. Break up long tasks. Any task over 50ms blocks input. Chunk expensive work and yield to the main thread between pieces, so a pending click gets served rather than queued. Modern browsers give you scheduler.yield() for exactly this; where it is unavailable, yielding via a scheduled task still beats one long block.
3. Stop doing expensive work inside event handlers. Filtering ten thousand rows on every keystroke, writing to local storage on every scroll, reading a layout property immediately after writing one — these are cheap on a development machine and brutal on a mid-range Android. Debounce input, batch reads and writes, and move genuinely heavy computation to a web worker.
4. Render the response before you finish the work. A user does not need the operation completed in 200ms; they need acknowledgement in 200ms. Show the pressed state, the spinner, the optimistic update, then do the work. This is a design decision as much as an engineering one, which is why it usually needs interface and experience design in the room.
5. Reduce hydration and DOM size. Client-side frameworks pay for interactivity by making the browser rebuild state after load, and a page with a very large DOM makes every style recalculation more expensive. Server components, islands architecture and simply rendering less all attack the same root cause.
6. Watch the consent and personalisation layer. Consent management platforms and personalisation tools frequently run synchronously and early, precisely when users are most likely to tap something. They are rarely on anyone's performance list because nobody in engineering chose them.
What it is worth
Two reasons to fund this work, and only one of them is search.
Core Web Vitals are part of Google's page experience signals, so a page that fails them is competing with one hand behind its back. That matters, and it is not the larger number.
The larger number is commercial. The Deloitte study Google commissioned across 37 brands and more than 30 million sessions found that a 0.1 second improvement in mobile load time lifted retail conversion rates by 8.4% and average order value by 9.2%, travel conversions by 10.1%, and lead-generation form progression by 21.6%. Those were load-time improvements rather than INP specifically, but the mechanism is identical: friction between intent and response costs money, whether it occurs before the page appears or after someone taps.
Where to start on Monday
Pull the Core Web Vitals report in Search Console and note the worst URL group. Load one of those URLs with the CPU throttled to 4x and interact with it the way a customer would. Then open your tag manager and count how many scripts are firing that nobody in the room can justify.
Questions we get asked
Why does Lighthouse give me a good score while the field data fails? Lighthouse is a lab test on a simulated device with no user interacting, and INP requires real interactions. A perfect lab score with failing field data is normal and means exactly what it looks like: your users' devices are slower than the simulation and they are tapping things the test never tapped.
How long until improvements show in Search Console? CrUX data is reported on a rolling 28-day basis, so allow around a month after a fix ships before the reported figure moves, and longer before the status of a URL group changes.
Does INP affect rankings directly? It is part of the page experience signals rather than a dominant ranking factor. Treat it as a tiebreaker in search and as a conversion issue everywhere else — the commercial case is stronger than the SEO one.
Our site is server-rendered. Are we safe? Server rendering helps LCP and does very little for INP, because INP is decided by whatever runs on the main thread after the page arrives. A server-rendered page carrying six tag manager containers will still fail.
Which single change helps most? Removing scripts. In nearly every audit we run, the largest single improvement comes from deleting third-party tags nobody can account for.
That third step alone fixes more INP failures than any refactor. If the number is still stubborn after it, that is what our speed and performance optimisation work exists for — and it is worth keeping honest afterwards with proactive maintenance, because performance is a state a site drifts out of, not a project that finishes.
Looking for more? Browse all resources.