What is Interaction to Next Paint (INP)?
Interaction to Next Paint (INP) is a Core Web Vital that measures how long a page takes to visibly respond after a user clicks, taps, or presses a key. It replaced First Input Delay in 2024. Slow INP is a leading cause of rage clicks and double submissions.
Interaction to Next Paint measures the gap between a user acting and the screen visibly reacting. Click a button; how long until anything on screen acknowledges it? INP tracks that latency across a page's interactions and reports a high-end value, so one janky menu can define the page's number. Google made it a Core Web Vital in March 2024, replacing First Input Delay.
The published thresholds: 200 milliseconds or under is good, over 500 milliseconds is poor. The behavioral thresholds are less forgiving.
Why slow response creates friction
People do not experience latency as a number. They experience it as doubt. A button that does nothing for 800 milliseconds is, as far as the user can tell, a button that did not work, so they click it again. Now there are two submissions in flight, and whichever error that produces is one the user caused by responding sensibly to your silence.
This is the mechanism that turns a performance issue into a rage click cluster. The element works. It is merely slow and mute, and slow plus mute is indistinguishable from broken during the only moment that matters.
What makes INP bad
The interaction-to-paint gap is main-thread time, and the usual thieves are:
- Heavy handlers. The click triggers a large synchronous chunk of JavaScript before anything renders.
- A congested main thread. Third-party scripts, analytics, and hydration work queue ahead of the user's interaction.
- Rendering cost. The response requires laying out an enormous DOM or an expensive style recalculation.
How to fix it
Two directions, and the second is underrated. First, make the work smaller or later: break long tasks up, defer what the response does not need, move computation off the main thread.
Second, acknowledge first and work after. Paint feedback immediately, a pressed state, a spinner, a disabled button, and then do the slow thing. An interaction that visibly reacts in 50 milliseconds and completes in two seconds feels fine. One that silently completes in 900 milliseconds feels broken. Users forgive latency; they do not forgive silence.
The check that closes the loop is behavioral: after an INP fix ships, repeated-click and double-submit behavior on the affected controls should fall. If the metric improved and the frustration signals did not, the slow interaction users actually suffer is not the one that was optimized. A free scan shows where users are already double-clicking your buttons.