INP: input delay, processing, presentation

A search results page feels fast after the first few seconds — but for the first 3 seconds after load, every button tap takes almost half a second to respond. The handlers themselves run in 8 ms. The rest of the time is not in the handler at all. This is the INP trap: the symptom is in the metric, but the cause is in the architecture.

What INP measures — and what replaced FID.

Interaction to Next Paint replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay before the first input’s handler could start — it missed the rest of the page lifecycle and missed interactions that were slow because the handler itself or the resulting render was heavy. INP measures the full input-to-paint latency of every click, tap, and key press, and reports a high percentile (effectively the worst, with a small allowance on pages with many interactions). One interaction’s latency is: from the moment the user’s input arrives to the next frame that visibly reflects a change. Good: ≤200 ms at p75.

The three parts of one interaction’s latency.

Any single interaction’s INP decomposes into three sequential parts:

1. Input delay — the time the input event waits before its handler can even start, because the main thread is busy with another task. This is the event-loop lesson directly: a long task in flight delays the input. The task can be JavaScript, style recalculation, or layout — whatever has the thread.

2. Processing time — how long your event handlers actually run. For most interactions on a well-written page this is 10–30 ms. If it is 200 ms, the handler is the problem.

3. Presentation delay — the time after the handlers finish for the browser to run style, layout, paint, and composite and put the result on screen. A handler that triggers a re-render of 5 000 nodes has a large presentation delay even if the handler logic ran fast.

A bad INP is always one of these three. Naming which part dominates is the whole diagnosis.

Optimising each part.

Input delay: Stop shipping long tasks. Break work into chunks under 50 ms, defer non-urgent JavaScript, and remember that hydration is one large long task early in the page’s life. Use scheduler.yield() between chunks to return control to the browser.

Processing time: Keep handlers small. If a handler must do heavy work, do the minimum synchronously to update the UI, then yield and continue — or move pure computation to a Worker. A powerful pattern: update the visible state synchronously and wrap the expensive downstream work in startTransition so the paint the user is waiting for is not blocked by it.

Presentation delay: Avoid forced synchronous layout in the handler (reading a layout property after a DOM write forces the browser to re-run layout immediately). Keep DOM updates small — a handler that re-renders 5 000 nodes has a heavy presentation delay regardless of how fast the handler logic was.

The hydration window is an INP trap.

The single most common INP failure on a server-rendered site is interactions that happen during hydration. The page is painted, the user sees a button and taps it — but the main thread is running the hydration long task. The tap’s handler may not even be attached yet, and even once it is, the input is queued behind the rest of hydration. INP records a large latency for that early interaction.

The pattern is distinctive: INP is poor only for interactions in the first few seconds, then fine. If the handlers were the cause, INP would be consistently poor for every interaction. The time-bounded pattern points straight at hydration. Every technique that shrinks hydration — Server Components, islands, selective and progressive hydration, code-splitting — is also an INP optimisation.