Performance

First Input Delay

Also called FID.

First Input Delay is the delay between a visitor's first interaction and the moment the main thread can start handling it. Google replaced it as a Core Web Vital with Interaction to Next Paint in March 2024.

How it is measured

FID measured only the wait before the first event handler began, not the handler's run time or the following paint. Good was 100 ms or less and poor was over 300 ms at p75.

It was recorded with the Event Timing API on the first click, tap, or key press. Scrolling and zooming were excluded, and pages with no interaction produced no value.

Worked example

A store loads a 340 KB bundle that parses until 2,600 ms on a mid-range phone. A visitor taps the menu at 2,100 ms and the browser starts the handler at 2,330 ms, so FID is 230 ms. After splitting the bundle, the same tap is handled at 2,110 ms, an FID of 10 ms.

Menu taps later in the session were always fast, which FID never showed.

How it differs

First Input Delay looked at one early input and its wait. Interaction to Next Paint looks at all interactions through the visit and includes handler time and rendering. FID could pass while INP failed, which is why it was retired.

Common errors

Still reporting FID as a current Core Web Vital. Reading a good FID as proof the page feels responsive. Ignoring handler duration. Assuming no value means a good value. Treating Total Blocking Time as the same thing, when it is a lab proxy.

In practice

Stop tracking FID as a pass or fail metric and look at INP for the same pages. If old reports still cite FID, use them only to spot long main-thread work during load.

See also

Interaction to Next Paint, Core Web Vitals

Sources

Count this on a real site.

Watch my website