How Do You Improve Interaction to Next Paint?
INP became a Core Web Vital in March 2024, replacing First Input Delay. The change caught many sites out, because FID measured only the delay before processing began, and almost everyone passed it. INP measures the entire path from input to the next frame painted, which is what a user actually perceives.
What does INP measure exactly?
For each interaction, the time from the user input until the browser paints the next frame reflecting it. That covers input delay, event handler execution and rendering. The page’s INP is drawn from the worst interactions across the visit rather than a single one.
Because it samples across the whole session, a page can pass on its first interaction and fail on a later one. Menus, filters, accordions and form validation are common late offenders, and a test that only loads the page and measures nothing will never surface them.
What causes poor INP?
Long tasks occupying the main thread so the browser cannot respond. Event handlers doing substantial synchronous work such as re-rendering large lists or recalculating layout. Third-party scripts running analytics or tag logic on interaction. Large component trees re-rendering on every state change.
The pattern underneath all of these is that JavaScript blocks the single main thread, and rendering cannot happen until it yields. Anything that runs for more than about 50 milliseconds without yielding is a candidate, and long tasks in DevTools identify them directly.
How do you fix it?
Yield to the main thread inside long tasks so the browser can paint between chunks. Move non-urgent work out of the handler and run it after the visual update. Debounce expensive handlers on input events. Reduce the amount of DOM updated in response to each interaction.
A useful pattern is to update the visible state first, then schedule the heavier work. If tapping a filter updates the button appearance immediately and recomputes the result list afterwards, the interaction feels responsive even though total work is unchanged.
Why is INP harder to test than LCP?
Because it requires interaction, and standard lab runs do not interact with the page. Lighthouse reports Total Blocking Time as a proxy, which correlates but is not the same measurement. Real INP data comes from field measurement or from manually interacting while profiling.
This makes INP the vital most likely to fail in field data while every lab tool reports green. If Search Console flags INP and your Lighthouse scores look healthy, that is the expected pattern rather than a contradiction, and the investigation has to happen through interaction.
Key takeaways
- INP measures input to next painted frame, with 200 milliseconds as the good threshold.
- It replaced First Input Delay in March 2024 because FID was too easy to pass.
- It samples the worst interactions across a visit, not just the first.
- Long main-thread tasks and heavy event handlers are the dominant causes.
- Lab tools cannot measure it directly, so field data usually surfaces the failure first.
Frequently asked questions
- Is Total Blocking Time the same as INP?
- No. Total Blocking Time is a lab proxy measuring main-thread blocking during load, while INP measures actual interaction latency across a real session. They correlate because both are driven by JavaScript on the main thread, but a page can have good TBT and poor INP.
- Do single-page applications struggle more with INP?
- Often, because interactions trigger client-side rendering rather than navigation, and large component trees can re-render on state changes. The fix is usually narrowing what re-renders and yielding during expensive updates rather than abandoning the architecture.
- Does INP apply to scrolling?
- No. Scrolling and zooming are excluded, since they are handled differently by the browser and are not discrete interactions. INP covers clicks, taps and key presses. Scroll performance is a real concern but measured separately from this metric.
- How do you find slow interactions in production?
- Use the web-vitals JavaScript library, which can attribute INP to the specific element and event that produced the worst interaction. That attribution is the difference between knowing INP is failing and knowing which button on which page is responsible.
Web Performance, BigBalli. We track Core Web Vitals definitions and thresholds as Google revises them, cross-checked against web.dev and Chrome developer documentation.