First Input Delay, abbreviated FID, was a web performance metric that measured the time between the user’s first input on a page, such as a click on a button or a tap on a link, and the moment the browser is actually able to start processing that interaction. It quantified the perceptible delay the user experiences when trying to interact while the browser is still busy with other tasks, typically executing code during the initial loading phase.
FID was one of the three original Core Web Vitals, but since March 12, 2024 it no longer is: Google replaced it with Interaction to Next Paint (INP), which considers all user interactions and not just the first one. Google then removed it from its tools (CrUX, PageSpeed Insights, Search Console). This entry explains what it measured and why it was replaced.
What FID records, in practice
FID focuses on a single event: the first time the user attempts to interact with the page. The recorded value is the time difference between the instant the input is received by the browser and the instant the main thread is able to respond to that input. If the main thread is busy, for example executing code, the input processing stays queued and the user perceives a delay.
It is important to emphasize that FID does not measure the total time needed to complete the response to the interaction, nor the rendering time of visual content. It measures only the initial delay before the browser starts handling the event. A low FID indicates that the page responds quickly to the first tap or click, while a high FID signals that the page is slow or blocked at the moment of interaction.
Responsiveness and load speed are not the same
FID should not be confused with the overall page load time. A page can load visually quickly and show its main content in a short time, yet still be unresponsive if the main thread is saturated with activity. Conversely, a page may take longer for visual loading but respond promptly to the first interaction. The two dimensions, loading performance and responsiveness, are distinct and complementary.
Google’s thresholds and how to read them
FID values are expressed in milliseconds and are collected in the field, that is, from real user interactions, not in the lab. Google had established reference thresholds to classify the experience: a FID below 100 milliseconds is considered good, a value between 100 and 300 milliseconds needs improvement, while a value above 300 milliseconds is considered poor.
These thresholds help developers assess page responsiveness. Since FID depends on real browsing conditions, such as device power and connection quality, values can vary significantly between different users. For this reason, a distribution of values is generally considered rather than a single isolated number.
Why it was replaced
FID measured only the initial delay of the first interaction: it did not see subsequent interactions or the time needed to show the result. With INP, Google measures the latency of all interactions during the visit, which better represents perceived responsiveness. When it was a Core Web Vital, FID was among the page experience signals; Google never declared a precise weight.
Today responsiveness is improved by working on INP: the causes (busy main thread, heavy JavaScript) and many of the interventions are the same ones that reduced FID.
What the first interaction delay depends on
The main factor determining FID is how busy the browser’s main thread is during the initial page load. When the thread is engaged in long tasks, user inputs must wait their turn before being processed. The longer the thread remains blocked, the greater the perceived delay.
Among the most common causes of a high FID are the execution of heavy code at startup, the processing of large amounts of data on the client side, and the presence of resources that block rendering. Page complexity and the number of interactive elements can also play a role, although FID concerns only the first interaction.
The impact of the user’s hardware and network
The characteristics of the user’s device and network significantly influence FID. Less powerful devices, with slower processors or limited memory, take longer to process code and respond to inputs. Similarly, slow connections can delay the loading of resources needed for page responsiveness.
Since FID is measured in the field, differences between users are inevitable. A page optimized for the most common devices and the typical connections of its audience tends to achieve better and more consistent values.
FID, INP, LCP and CLS compared
To understand the role of FID, it is useful to compare it with the other metrics that describe a page’s experience. The current Core Web Vitals are LCP, INP and CLS; FID is included in the table for comparison.
| Metric | What it measures | Unit of measure | Scope |
|---|---|---|---|
| FID | Delay of the first interaction | Milliseconds | Initial responsiveness |
| LCP | Display time of the main element | Seconds | Visual loading |
| CLS | Visual instability of elements | Dimensionless score | Layout stability |
| INP | Responsiveness to all interactions | Milliseconds | Overall responsiveness |
| TTFB | Initial server response time | Milliseconds | Server response |
Reducing browser work at startup
To reduce FID, and today INP, you need to reduce the time the main thread stays busy. The most effective strategies aim to limit the work the browser does at startup and to distribute tasks better over time. Below are the most common and established practices.
- Reduce the amount of code executed at page startup, loading only what is strictly necessary for the first interaction.
- Break long tasks into shorter chunks so that the main thread can respond to inputs between one task and the next.
- Defer the execution of non-essential features until after the initial load or until they are actually needed.
- Optimize third-party resources, which often introduce heavy code and slow down page responsiveness.
- Reduce the size of transferred files by applying compression and minification to text resources.
- Use lazy loading for non-critical resources, preventing them from blocking input processing.
- Monitor field values to identify pages with the greatest delays and intervene in a targeted way.
- Test performance on devices and connections representative of your audience, not only on powerful machines.
Frequently asked questions about FID
What does FID stand for?
FID is the abbreviation of First Input Delay, a term that can be translated as the delay of the first interaction. It indicates the time between the user’s first input and the moment the browser starts processing it.
Is FID still a Core Web Vitals metric?
No. FID was one of the three original Core Web Vitals metrics, but since March 12, 2024 it has been replaced by Interaction to Next Paint, which offers a more complete measure of responsiveness. It remains useful as a concept for understanding how the main thread affects page response.
What is a good FID value?
A value below 100 milliseconds is considered good. Values between 100 and 300 milliseconds indicate the need for improvement, while values above 300 milliseconds are considered poor.
Is FID measured in the lab or in the field?
FID was measured only in the field, that is, through real user interactions. In the lab, the closest indicator is Total Blocking Time.
Why can FID be high even if the page loads quickly?
Because FID does not depend on visual load time, but on how busy the main thread is. If the browser is engaged in other tasks when the user interacts, the input waits and the delay increases.
Does improving responsiveness help ranking?
It can contribute to a limited extent. Responsiveness is part of the page experience signals (today measured with INP), but Google does not declare its weight and content relevance matters more. The main benefit is for those who use the site.
Do you have this problem?Does your site respond late to the user’s first click or tap, making them waste time?A high FID disappoints those who interact and can cost you conversions. We analyze Core Web Vitals and optimize loading for immediate interaction.Discover the Core Web Vitals service
Related entries:
Core Web Vitals Total Blocking Time INP (Interaction to Next Paint) CLS Core Web Vitals