What is First Input Delay (FID)?
First Input Delay (FID) measured one specific moment: a visitor taps a button, clicks a link or presses a key for the first time, and the browser is busy. FID was the wait between that first input and the instant the browser's main thread was free to start handling it. It did not measure how long the handling took or when the screen updated, only the delay before processing began. Google set the good threshold at 100 milliseconds.
It was one of the three original Core Web Vitals, launched in 2020 alongside Largest Contentful Paint and Cumulative Layout Shift. In March 2024 Google retired it and replaced it with Interaction to Next Paint (INP), which measures the whole of every interaction across the visit rather than the start of the first one.
Why it matters
Why FID matters
It still matters because the problem it measured is still the problem. A page that looks loaded but ignores a tap feels broken, and the cause is almost always JavaScript: large bundles parsing, third-party tags executing, long tasks hogging the main thread while the visitor waits. FID put a number on that for the first time and taught a generation of teams to think about responsiveness as separate from load speed.
It also matters because its reports are still around. Older performance audits, historical Search Console data and plenty of agency decks quote FID. Knowing what it measured, and why it was replaced, is how you read those documents correctly and avoid optimizing for a metric nobody scores any more.
In practice
How FID works in practice
- 01
FID was collected from real visitors, since it needs a real interaction; lab tools like Lighthouse used Total Blocking Time as a stand-in. It was reported at the 75th percentile in the Chrome User Experience Report and in the Core Web Vitals report in Search Console. Most sites passed it easily, which was the first sign it was too lenient: a page could clear 100 milliseconds on the first tap and still stutter on every one after.
- 02
The fixes for FID are the fixes for INP, which is why the work transfers. Break long JavaScript tasks into smaller ones so the main thread gets gaps. Defer scripts that are not needed for the first screen, and load third-party tags late or behind consent. Remove unused code from bundles. Move heavy computation into web workers. Measure with INP now, but the diagnosis, what is blocking the main thread, is unchanged.
Watch out
What people get wrong about FID
Still reporting it. FID has not been a Core Web Vital since March 2024, and a dashboard that shows it is showing a number Google no longer uses. The second mistake is assuming a good FID meant a responsive page. It measured only the delay before the first interaction was processed, so a page could pass FID and still feel sluggish for the rest of the visit, which is exactly the gap INP was built to close. The third is treating it as a loading metric. Load speed is LCP; FID was about what happens when the visitor tries to do something.
