Interaction to Next Paint

Input delay: the time between the interaction and the event handler starting, spent waiting for the main thread to become free.

Processing time: how long the event handlers themselves take to run.

Presentation delay: the time between the handlers finishing and the browser painting the next frame, which includes recalculating styles and layout.

A bad score can come from any of the three, and the remedy differs: input delay means something else was occupying the thread, processing time means the handler is doing too much, presentation delay usually means the resulting DOM change is expensive to render.

Clicks, taps and key presses. Hovers and scrolls are not interactions for this purpose.

Every such interaction during the visit is measured, and the reported value is near the worst — the highest for pages with few interactions, and a high percentile for pages with many.

That whole-visit scope is the substantive change from First Input Delay: an application that responds instantly on load and stalls after ten minutes of use is now measured honestly.

It cannot be measured without someone interacting, so a synthetic laboratory run reports no value for it.

Long tasks on the main thread — any single block of JavaScript running for more than 50 milliseconds — which delay every interaction that arrives while they run.

Event handlers doing substantial work synchronously before yielding, such as re-rendering a large list in response to a keystroke.

Third-party scripts, particularly advertisement and analytics code, which execute on the same single thread as everything else.

Very large DOM trees, which make every style recalculation and layout pass expensive and therefore lengthen the presentation delay.

Frameworks that re-render broadly in response to small state changes.

Field data is the only complete source. The Chrome User Experience Report and Search Console both report it for URLs with enough traffic.

In the browser's performance panel, recording while interacting shows each interaction broken into its three phases.

Breaking long tasks into smaller pieces, and yielding to the main thread between them, addresses input delay directly.

Moving work off the critical path — deferring non-essential scripts, using a web worker for heavy computation — addresses the underlying cause rather than the symptom.