Interaction to Next Paint
INP measures the latency from a user interaction to the next visual response across all interactions, reporting close to the worst meaningful one, and is the Core Web Vitals responsiveness metric.
Definition
Interaction to Next Paint observes every tap, click, and key press during a page lifetime and measures the delay from input to the next presented frame that reflects it. The reported value approximates the highest percentile of interactions rather than the average, replacing First Input Delay, which only saw the first interaction.
Context and scope
Optimized for UIs where every click and keystroke must feel instant: checkout flows, editors, search-as-you-type. Field data comes from RUM with event timing and long animation frame entries.
Common misconceptions
- INP is the average interaction latency — it reports near the worst interaction, so one slow click dominates
- Only long tasks matter — slow style and layout phases with fast tasks can still delay the next paint
- Debouncing fixes INP — delaying the response moves latency later; INP requires the next paint that acknowledges the input
Anti-patterns
- Running heavy synchronous work in input handlers and deferring the visual update
- Optimizing first-load metrics while the p99 click on a filtered grid takes 800ms
- Splitting code at route level but leaving the interaction handler in a lazily fetched chunk
Related concepts
Related examples
Authoritative source
What it is
Responsiveness is per-interaction: the user acts, and the page must present a frame acknowledging it. INP tracks all interactions and reports a high-percentile view so a single neglected flow cannot hide behind good averages. It replaced First Input Delay in Core Web Vitals.
How it works
Event Timing entries expose inputDelay, processing duration, and presentation time per interaction. The next paint requirement means updating visible state synchronously enough to make the next frame: compute minimal feedback, defer the rest with scheduler primitives, and keep handlers lean. Long animation frame attribution identifies the culprit code.
When to optimize
Search inputs, filters, add-to-cart, and any handler bound to rapid repeated interaction. Break handlers into feedback-now and work-later phases; yield to the renderer between them; move pure computation to workers where transfer costs permit.
Pitfalls
Debounce-only fixes shift perceived latency rather than removing it: the first keystroke still needs a fast ack. Async handler patterns that never update visible state until completion leave INP unchanged. Field data over 28-day windows lags fixes — validate locally with synthetic traces first.