First Input Delay is published by General Action, the company that makes Emdash. When we recommend Emdash, we are recommending our own product. About this site
First Input Delay
What First Input Delay is
Section titled “What First Input Delay is”First Input Delay (FID) is the time from a visitor’s first interaction with a page (a click, a tap or a key press) to the moment the browser is able to begin running event handlers for that interaction. That is the definition Google’s Chrome team published on web.dev. FID is a measure of waiting: the visitor has acted, and the browser’s main thread is too busy to start responding.
FID was one of Google’s three Core Web Vitals from 2020 until March 12, 2024, when Interaction to Next Paint (INP) replaced it.
FID thresholds
Section titled “FID thresholds”| Rating | FID at the 75th percentile |
|---|---|
| Good | 100 ms or less |
| Needs improvement | More than 100 ms, up to 300 ms |
| Poor | More than 300 ms |
The 100 ms target and the 75th-percentile rule are stated in web.dev’s FID article: sites “should strive to have a First Input Delay of 100 milliseconds or less”, measured at “the 75th percentile of page loads, segmented across mobile and desktop devices”. The 300 ms boundary is the one Chrome’s tooling used. You can still read it in the last version of Google’s web-vitals library that supported the metric, which defines FIDThresholds as [100, 300].
The percentile matters. A page passes when at least 75% of its page loads have an FID of 100 ms or less, so a fast median does not make up for a slow tail on low-end phones.
What FID measures and what it leaves out
Section titled “What FID measures and what it leaves out”Picture a page that is still loading. A script is halfway through a 300 ms task when the visitor taps “Add to cart”. The browser cannot run the tap’s event handler until that task finishes, 150 ms later. The FID for that page load is 150 ms. Whatever the handler then does, and however long the screen takes to change, is not counted.
That narrow scope is deliberate, and it has four parts.
- Input delay only. In web.dev’s words, “FID only measures the ‘delay’ in event processing.” It does not include the time the event handlers take to run or the time the browser needs to paint the result.
- The first interaction only. One value per page load. A slow menu on the tenth click never shows up.
- Discrete inputs only. Clicks, taps and key presses count. Scrolling and zooming are continuous actions and are not measured.
- The field only. FID “requires a real user to interact with your page”, so it cannot be produced by a lab tool such as Lighthouse. Lab tools use Total Blocking Time as a stand-in.
Google’s stated reasons for focusing on the first input were that it shapes the first impression of a site, and that the worst responsiveness problems at the time happened during page load.
One consequence is easy to miss: a page load with no interaction has no FID at all. Visitors who read and leave are not in the data.
What causes a long input delay
Section titled “What causes a long input delay”The browser runs JavaScript, style, layout and input handling on one main thread, one task at a time. If a task is running when the visitor acts, the input waits in a queue. Any task that runs for more than 50 ms is called a long task, and long tasks during page load are the usual cause of a poor FID.
The typical sources are large JavaScript bundles being parsed and executed at startup, framework hydration, and third-party scripts. How to improve First Input Delay covers the fixes with code.
Where FID stands today
Section titled “Where FID stands today”FID is deprecated. This is the sequence, each step from a primary source.
| Date | What happened |
|---|---|
| 2018 | FID is added to the Chrome UX Report as an experimental metric, starting with the June 2018 dataset (CrUX release notes). |
| 2020 | FID becomes one of the three Core Web Vitals (web.dev). |
| May 2022 | Chrome announces INP as an experimental metric. |
| May 10, 2023 | Google announces that INP will replace FID in March 2024 (Google Search Central). |
| March 12, 2024 | INP replaces FID as a Core Web Vital. Search Console stops showing FID (web.dev). |
| May 13, 2024 | Version 4.0.0 of the web-vitals library deprecates onFID(). |
| September 9, 2024 | Chrome’s deadline for ending FID support. The CrUX release notes published the next day record FID’s removal from the CrUX API, and the August 2024 dataset is the last one in BigQuery to contain it. |
| May 7, 2025 | Version 5.0.0 of the web-vitals library removes onFID() (changelog). |
What that means in practice, as of November 2026:
- PageSpeed Insights reports field data for FCP, LCP, CLS, INP and TTFB. FID is not among them, and the Core Web Vitals assessment uses INP (PageSpeed Insights documentation).
- The Chrome UX Report no longer lists FID among its metrics. Historical FID data remains in the BigQuery tables up to August 2024.
- Search Console’s Core Web Vitals report uses INP.
- Browsers still expose the underlying measurement. The Event Timing API’s
first-inputentry is how FID was always calculated, and it is unaffected by the metric’s retirement. See How to measure First Input Delay.
Why Google replaced FID
Section titled “Why Google replaced FID”FID was easy to pass. In May 2023, the Chrome team reported that 93% of sites had good FID on mobile devices, while only 65% had good INP. A metric nearly everyone passes says little about which pages feel slow.
The two limits above explain the gap. FID looked at one interaction and at one part of it. INP observes every click, tap and key press during the visit, measures each one from the input to the next frame painted, and reports roughly the worst. FID vs. INP compares them point by point.
What to do now
Section titled “What to do now”- Measure INP in the field. Use PageSpeed Insights for a quick read from Chrome’s public data, or collect your own with the web-vitals library and its
onINP()function. A good INP is 200 ms or less. - Use Total Blocking Time in the lab. Lighthouse reports it on every run, which makes it the practical number to budget against in CI.
- Fix long tasks. Split big tasks, yield to the main thread, load less JavaScript up front, and move heavy computation to a worker. The steps are in How to improve First Input Delay.
- Retire FID from dashboards and targets. If you keep a FID chart for continuity, compute it yourself from
first-inputentries and label it as a legacy metric. Do not use it to decide whether a page is responsive.
Frequently asked questions
What is First Input Delay?
First Input Delay (FID) is the time from a visitor's first interaction with a page, such as a click, a tap or a key press, to the moment the browser is able to begin running event handlers for that interaction. It measures how long the first input waited, not how long the handlers took or when the screen updated.
What is a good First Input Delay?
A good FID is 100 milliseconds or less, measured at the 75th percentile of page loads and separately for mobile and desktop. Above 300 milliseconds is rated poor. Anything in between needs improvement.
Is First Input Delay still a Core Web Vital?
No. Interaction to Next Paint (INP) replaced First Input Delay as the responsiveness metric in the Core Web Vitals on March 12, 2024. Chrome ended support for FID in its tools on September 9, 2024, and the metric was removed from the Chrome UX Report.
Can I still measure First Input Delay?
Yes, in your own analytics. Browsers that implement the Event Timing API still report a first-input performance entry, and FID is that entry's processingStart minus its startTime. Google's tools no longer report it, and the web-vitals library removed its onFID function in version 5.
Why can't Lighthouse measure First Input Delay?
FID needs a real person to interact with the page, and a lab tool such as Lighthouse loads the page without one. Lab tools report Total Blocking Time instead, which adds up how long the main thread was blocked by long tasks during load.
Does fixing First Input Delay still help?
Yes. Input delay is the first of the three phases that make up an INP interaction, and it has the same cause as before, a main thread that is busy when the visitor acts. Breaking up long tasks and shipping less JavaScript improves both metrics.