Quick answer
First input delay (FID) measured the time from a user’s first interaction with a page to when the browser could begin processing event handlers for it. It was a Core Web Vital until 12 March 2024, when Interaction to Next Paint (INP) replaced it.
Formula: FID = time handler processing starts − time of first input
What is first input delay?
First input delay (FID) measures the time from a visitor's first interaction with a page (a click, tap or key press) to the moment the browser can start running the code that responds to it. It captures how long the page ignores the user because the main thread is busy, usually with JavaScript.
FID was one of Google's three Core Web Vitals from 2020. On 12 March 2024 Google replaced it with Interaction to Next Paint (INP), and FID is no longer a Core Web Vital. You will still see it in older reports, articles and tools.
FID thresholds
Google's thresholds, assessed at the 75th percentile of real page loads:
| Rating | FID |
|---|---|
| Good | 100 ms or less |
| Needs improvement | 100–300 ms |
| Poor | over 300 ms |
What FID measures, and what it misses
An interaction has three parts. A worked timeline for one tap on a "Add to cart" button (sample):
| Phase | From | To | Duration | Counted in FID? | Counted in INP? |
|---|---|---|---|---|---|
| Input delay | Tap at 1,200 ms | Main thread free at 1,380 ms | 180 ms | Yes | Yes |
| Processing | 1,380 ms | Handlers finish at 1,470 ms | 90 ms | No | Yes |
| Presentation delay | 1,470 ms | Next frame painted at 1,510 ms | 40 ms | No | Yes |
| Total | FID = 180 ms | INP = 310 ms (if this is the slowest interaction) |
So FID only covered the waiting part of the first interaction. A page could have a good FID while every later click was slow, or while event handlers themselves took hundreds of milliseconds. INP fixes both gaps by considering all interactions on the page and their full duration until the next paint.
Why FID was replaced
- First interaction only. Many slow interactions happen later, after the page has loaded.
- Delay only. Slow event handlers and rendering were invisible.
- Too easy to pass. In Chrome's field data, the large majority of sites already had good FID on mobile, so it no longer separated fast sites from slow ones.
Related lab metrics
FID needs a real user to interact, so it can only be measured in the field. In lab tools such as Lighthouse, total blocking time (TBT) and "max potential FID" (the longest task during load) are used as proxies: both measure how long the main thread is blocked by long tasks.
How to improve input delay
The causes of high FID are the same as the input-delay part of INP:
- Break up long tasks. Split JavaScript work into chunks under 50 ms and yield to the main thread between them.
- Ship less JavaScript. Remove unused code, split bundles, defer non-critical scripts.
- Delay third-party scripts (tags, widgets, A/B testing scripts) until after the page is interactive.
- Avoid heavy work on load such as hydrating large components the user cannot see yet.
- Move work off the main thread with web workers where possible.
In TapCub
TapCub's performance report measures Core Web Vitals from real visits and reports INP, together with LCP, CLS, time to first byte and first contentful paint, at P75, P95, median or average. It does not report FID, because INP replaced it. If you are comparing against an old FID baseline, read INP's input-delay share as the closest equivalent. See Core Web Vitals and check Core Web Vitals.
Sources
- web.dev. First Input Delay (FID).
- web.dev. Interaction to Next Paint becomes a Core Web Vital on March 12.
- MDN Web Docs. First input delay.
Was this explanation clear?
We use your answers to fix and expand this page.
Couldn’t send. Please try again in a minute.
Thanks for the feedback. We’ll use it to improve this page.You’ve already sent feedback on this page. Thanks.
Technical Engineer
Focuses on tracking code, SDKs, and API integrations, with practical guidance on implementation checks and troubleshooting.