Interaction to Next Paint measures how long your page takes to visibly respond when someone taps, clicks or types. The threshold is 200 milliseconds at the 75th percentile, and roughly 43 percent of sites do not meet it. It is the most commonly failed Core Web Vital, and the one teams find hardest to move.
The reason it is hard is structural. LCP and CLS are usually fixed by changing how assets are delivered. INP is usually fixed by changing how much JavaScript runs, which means changing the application.
Why INP Replaced FID
First Input Delay measured only the gap between a user interacting and the browser beginning to process that interaction. It ignored everything after. A page could start processing a click in 10 milliseconds, spend 800 milliseconds computing, and score beautifully while feeling broken.
INP measures the whole journey through to the next frame painted on screen, and it does it for every interaction during the visit rather than only the first, reporting roughly the worst one. It is a much more honest measure of whether a page feels responsive.
The Three Phases
Every interaction breaks into three parts, and knowing which one is slow determines the fix entirely.
Input delay
The time between the user acting and your event handler starting. This is time lost because the main thread was already busy with something else: a third-party script, hydration, an analytics beacon, a long-running timer.
Processing time
How long your event handlers actually take to run. Heavy state updates, expensive re-renders and synchronous work that should have been deferred all land here.
Presentation delay
The time from your handlers finishing to the browser painting the result. Large DOM updates, forced synchronous layout and expensive style recalculation dominate this phase, and it is the one most teams forget to measure at all.
Finding the Problem
Start with field data, because INP is about real interactions on real devices. The Core Web Vitals report in Search Console tells you which URL groups fail. The web-vitals JavaScript library can report INP with attribution, naming the specific element and phase responsible, which is the single most useful diagnostic available.
Then reproduce it locally. In Chrome DevTools, throttle the CPU to 4x or 6x slowdown to approximate a mid-range Android device, record a performance trace, and interact with the page. Long tasks appear as red-flagged blocks. Anything over 50 milliseconds is a candidate.
Do not skip the throttling step. On a development machine almost every site passes INP, which is exactly why so many teams are surprised by their field data.
Break Up Long Tasks
A long task is any block of JavaScript occupying the main thread for more than 50 milliseconds. While it runs, the browser cannot respond to anything. The fix is to stop doing everything at once.
Yield back to the browser between chunks of work. The modern approach is scheduler.yield() where available, which yields while keeping your place in the queue. Where it is not, breaking work across tasks with a short timeout achieves a similar result less elegantly.
The pattern that matters most: do the visible update first, yield, then do the bookkeeping. If a click should toggle a menu and also fire analytics, update the menu, let the browser paint, then send the analytics. The user sees a response in a frame instead of waiting for work they do not care about.
Get Third-Party Scripts Off the Critical Path
Tag managers, chat widgets, heatmap tools, A/B testing scripts and consent managers are, in aggregate, the most common cause of input delay on ordinary business websites. Each one seemed reasonable when it was added.
- Audit what is actually loading. The list is usually longer than anyone expects and includes tools nobody has looked at in a year.
- Load non-essential scripts with
asyncordefer, or delay them until after first interaction. - Be particularly wary of A/B testing and personalization tools that block rendering by design to avoid flicker.
- Remove anything nobody is using. This is the highest-return performance work available and it costs nothing.
Reduce the Work of Rendering
Presentation delay is dominated by how much the browser has to recalculate after your code runs.
- Keep the DOM small. Thousands of nodes make every style recalculation expensive. Virtualize long lists.
- Avoid forced synchronous layout: reading a geometric property such as
offsetHeightimmediately after writing a style forces the browser to lay out on the spot. Batch reads, then writes. - Use
content-visibility: autoon large offscreen sections so the browser can skip rendering work until they matter. - In component frameworks, memoize expensive subtrees and keep state updates narrow. A state change at the top of a large tree that re-renders everything is a classic INP failure.
Give Immediate Visual Feedback
Some work genuinely takes time. A search that has to hit the network cannot return in 200 milliseconds.
What INP measures is the time to the next paint, not the time to completion. Painting a loading state, a pressed button style or a skeleton row satisfies the metric and, more importantly, tells the user their action registered. Optimistic UI updates work the same way: show the expected result immediately, reconcile when the server responds.
Verify in the Field
Local improvements are necessary but not sufficient. Confirm in field data, remembering that Search Console uses a 28-day rolling window, so a real fix takes weeks to show fully. Watching the metric for a few days and concluding nothing changed is the most common self-inflicted wound in performance work.
For the wider context on how INP fits alongside the other metrics, see our Core Web Vitals guide.
