First Entry Delay (FID) is the delay between when a user first interacts with your page and when the page responds. It measures responsiveness and is one of the three Core Web Vitals metrics that Google uses to measure page experience.
Examples of interactions:
- Click on a link or button.
- Entering text in an empty field.
- Selection from a drop-down menu.
- By clicking on a checkbox.
Some events such as scrolling or zooming are not counted.
Let’s see how fast your FID should be and how to improve it.
A good FID value is less than 100ms and should be based on data from the Chrome User Experience Report (CrUX). This is data from real Chrome users who are on your site and have agreed to share this information. You need 75% interactions to respond in less than 100ms.
Your page can be categorized into one of the following buckets:
- Good: <=100ms
- To be improved: >100 ms and <=300 ms
- Poor: >300ms
95.3% of sites are in the correct FID category in April 2023. This is an average across the entire site. As we mentioned, you need 75% of interactions to respond within 100ms to be this good here.
The majority of pages on most sites pass the CWV check for FID. I don’t think it’s really the best way to measure responsiveness, and Google will replace FID with Interaction to Next Paint (INP) in March 2024. Instead of just looking at the first input, INP looks at the latency of all interactions that a user does.
When we ran a study on Core Web Vitalswe found that almost no one needs to worry about FID on desktop connections, and very few need to worry about it on mobile.
Few sites need to worry about FID, even on slower connections, because most of their pages pass.
Our page-level data from the study told the same story. FID doesn’t seem to be an issue for most pages.
The only FID number that counts comes from the Chrome User Experience Report (CrUX)which is data from actual Chrome users who choose to share their data.
It’s called field data and gives you the best idea of actual FID performance under different network conditions, devices, caching, etc. This is also what you will actually be measured on by Google for Core Web Vitals.
For consistent and reproducible testing, there is also laboratory data, which tests under the same conditions. FID is not available in lab tests because the test tools do not click anything. However, you can use Total Block Time (TBT) as an alternative metric. By improving blocked processes, you will also improve your FID.
Measure FID for a single URL
Page speed information extracts page-level field data that you cannot otherwise query in the CrUX dataset. It also gives you origin data so you can compare page performance to the whole site and runs Google based lab tests Headlight to give you TBT.
Measure FID for many URLs or an entire site
You can get CrUX data in Google Search Console which is categorized into good, needs improvement and bad.
Clicking on any of the issues gives you a breakdown of the affected page groups. Groups are pages with similar values that likely use the same template. You make the changes once in the template, and it will be fixed on all pages in the group.
If you want both lab data and large-scale field data, the only way to achieve that is to use the PageSpeed Insights API. You can connect to it easily with Ahrefs’ Site Audit and get reports detailing your performance. This is free for verified sites with a Ahrefs Webmaster Tools (AWT).
Note that the Core Web Vitals data displayed will be determined by the user agent you select for your scan during setup. If you are exploring from mobile, you will get mobile CWV values from the API.
When a task is running, a page cannot respond to user input. It is the delay that makes itself felt. The longer the task, the longer the delay experienced by the user.
In PageSpeed Insights, you will see a TBT tab that has issues related to main thread blocking. These are the issues you will want to address in order to improve the FID.
Most pages pass FID checks. However, if you need to work on FID, you can only work on a few things:
Usually a script being downloaded blocks the parser while downloading and running. Async will let the parse and download happen at the same time but still block the parse while the script is running. Defer will not block parsing while downloading and will only run after HTML parsing is complete.
Which should you use? For anything you want earlier or has dependencies, I’d lean towards async.
For example, I tend to use async on crawl tags so more users get registered. You’ll want to defer anything that isn’t needed or doesn’t have dependencies. Attributes are fairly easy to add.
Check out these examples:
<script src="https://www.domain.com/file.js" async></script>
<script src="https://www.domain.com/file.js" defer></script>
3. Separate long tasks
4. Use web workers
5. Use pre-rendering or server-side rendering (SSR)
Even if the FID is replaced by the INP in March 2024, it is still worth working on improving the FID. The same things you work on to improve TBT and FID should also improve INP.
If you have any questions send me a message on Twitter.