First Input Delay (FID)
Slap yourself if
You think FID measures how fast your app responds to clicks.
Why this exists
FID exists because users don’t care when pixels paint — they care when the app listens. Early pages often look ready while the main thread is still busy, creating a gap between perceived readiness and actual interactivity.
Mental model
FID measures how long the main thread ignores the user. It’s not about handler speed; it’s about how long the browser can’t even start handling input.
- The user performs their first interaction (click, tap, key).
- The browser queues the event.
- The main thread is busy running other tasks.
- FID is the delay until the event handler can begin execution.
- Optimizing handler logic while ignoring main-thread blocking.
- Assuming async code prevents input delay.
- Measuring FID in synthetic tests where no real input exists.
- Confusing FID with overall interaction latency.
First Input Delay measures the time between a user’s first interaction and when the browser is able to start processing that event, reflecting main-thread availability rather than handler execution time.
- Long tasks during initial load
- Heavy hydration or initialization work
- Large synchronous bundles executed on startup
- FID discussed without mentioning main-thread contention
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.