First-input delay and steady-state delay must be measured separately
Aliases: FID · cold versus warm latency · Interaction to Next Paint
What it is
In the same session, the first click is often slower than the fifth. The main thread is still running boot scripts, fonts are arriving, the JIT is cold, and the first input has to barge into a jam. First-input delay measures that jam. Steady-state latency measures how much tracking cost remains once the jam has cleared. The two ledgers must not be averaged into one “response time”. The average dilutes the single slow first hit — which is exactly the hit people use to size the product.
Why it happens
Startup is non-stationary. The event loop is occupied by parse, layout, hydration and permission sheets, and input events queue. In that first delay, actual input handling is a sliver; most of it is waiting to be served. After steady state those one-shot jobs vanish, and what remains is the architecture’s built-in tracking cost. Mix both stretches in one histogram and optimisers shave the steady-state tail while missing the one decisive dull beat in the boot window.
Judgement is asymmetric too. A slow first hit sets a prior of “this app is heavy”; later speed needs many trials to revise it. First input is not only a technical peak. It is the experiential anchor.
Studying it
Sample in time slices: first 3 s of the session, seconds 3–10, after 10 s — each with its own input-to-photon distribution. On the web, First Input Delay and Interaction to Next Paint are engineering approximations of that slicing; a lab should still timestamp on the device.
Independent variables: whether the boot window is included, whether the app was warmed, which ordinal input. Dependent variables: P50 / P95 latency, shape of the sliced distributions, whether “first hit” and “once fluent” ratings come apart.
Benchmarks that start only after the app is “ready” systematically under-report the first hit users actually meet. Field logs that drop the boot window bias conclusions optimistic.
Where it stops holding
Always-on, already warm tools (an editor left open) barely have a first-input problem; steady state is the main field. Ad SDKs and autoplay video stretch the “boot window” to tens of seconds; slice boundaries have to follow the product. Games that only open input after a loading screen should not file load duration under this metric — that is not first-input delay. Automated tests that tap once to “wake” the UI before timing will measure only steady state.
Applying it
- Split the metric in two columns: first input after a cold start, and continuous input after a minute of use. Both columns have to pass.
- Do not block input during boot: a skeleton that can be tapped, a first screen that can already scroll, non-critical scripts deferred until after the first interaction.
- Do not let the lab tap three “warm-up” times before the clock starts.
- How to check: reinstall (or clear cache), open, tap the main button immediately, record that first hit. Compare with the tenth tap a minute later. A product that only reports the later hit is hiding the first one people meet every day.