Interaction to Next Paint (INP): Input Delay, Processing, and Presentation
- Last updated
- Prerequisites:
- Browser Event Loop phases
- Layout reflow & compositor paint pipeline
- browser
- web-vitals
- inp
- performance
- event-timing
- main-thread
Read at your depth
The practical view
Interaction to Next Paint (INP) is a Core Web Vital replacing First Input Delay (FID). It measures responsiveness by tracking the latency of all user interactions (clicks, taps, keypresses) throughout the entire page lifecycle. INP represents the worst (or 98th percentile) interaction latency, divided into three phases: Input Delay, Processing Duration (event handler execution), and Presentation Delay (style, layout, paint, and frame rendering). Good INP is <= 200ms.
The same idea in other frameworks
`useTransition()` and `startTransition()` yield priority to urgent user input to prevent INP spikes.Zoneless change detection and signal writes reduce synchronous full-tree dirty checking latency.Vue async component loading and transition scheduling keep event handlers under the 50ms task budget.Svelte compiled direct DOM updates minimize JavaScript processing duration.Legacy vs modern
Blocking Event Handler vs Yielded Async Task Pipeline
Synchronous heavy operations block the main thread and spike INP; yielding to the scheduler allows the browser to paint the feedback frame immediately.
button.addEventListener('click', () => { computeHeavyReport(); updateUI(); }); // ❌ Spikes INPawait scheduler.yield(); // ✅ NEW: Allows browser to paint feedback before heavy workInterview gotchas
Context
Interviewers test your historical and architectural knowledge of Core Web Vitals.
The mechanical answer
FID only measured the *input delay* (waiting time) of the *very first* user interaction, ignoring the execution time of event listeners and subsequent rendering/painting time entirely. It also ignored all subsequent interactions on the page. INP measures the *total roundtrip duration* (Input Delay + Processing Duration + Presentation Delay) for *all* interactions throughout the session, accurately reflecting real-world UI responsiveness.
Trap
Do not state that FID measured click-to-render latency. FID only measured the time from click to the moment the JavaScript handler *began* executing.
Context
This tests whether you understand rendering pipeline bottlenecks beyond JavaScript execution time.
The mechanical answer
Presentation Delay is the duration between when event listeners finish executing (`processingEnd`) and when the updated visual frame is physically presented on screen (`presentationTime`). It spikes due to expensive Style Recalculations, deep DOM Layout Reflows, massive Paint operations, or compositor thread contention (e.g. huge GPU texture uploads).
Trap
A fast event handler (<10ms JS execution) can still have a failing INP (>300ms) if it triggers massive DOM mutations requiring expensive layout and paint passes.