FID
First Input Delay
Replaced by INP in March 2024. Only measured delay before the first interaction.
- Good: ≤ 100ms
- Needs improvement: ≤ 300ms
- Poor: > 300ms
Main thread
Input delay 180 ms
The main thread is busyYou tap during a long taskThe browser can only respond once the task endsThe handler finally runs
What was FID?
First Input Delay (FID) measured the delay between the user’s first interaction and when the browser began processing the event handler. It was a Core Web Vital from 2020 until March 2024, when it was replaced by INP.
What did it measure?
FID captured one dimension of interactivity — the input delay of the very first interaction. It missed processing time, presentation delay, and all subsequent interactions throughout the session.
What was measured
Considered
- The first click, tap, or key press after the page starts loading
- Only measured while the main thread was busy at the moment of first interaction
Excluded
- All subsequent interactions after the first (INP measures all of them)
- Processing time and presentation delay (INP measures both)
- Scroll, zoom, and continuous gestures
Why FID was replaced
FID had significant blind spots that INP was designed to address.
01
Why FID was replaced
FID only measured one moment in the page lifecycle — the delay before the browser started handling the very first click or key press.
Fix If you are still tracking FID: optimise it the same way as INP input delay — break up long tasks on the main thread. Then migrate your monitoring to INP.
02
How INP supersedes it
INP measures every interaction across the full page visit, and measures the complete latency rather than just the delay phase of one interaction.
Fix Focus your optimisation efforts on INP. A good INP score implies FID would have been good too, but not vice versa.
Need help fixing your FID?
Root cause analysis, not plugin guessing. Baseline from field data or lab — wherever you are.
Start an Engagement