First Input Delay (FID) measures the delay between a user’s first interaction and the moment the browser can respond.
This metric is tricky to measure, as it requires real user input. However, FID is an important part of understanding the user experience on your site.
And as part of Google’s Core Web Vitals, it also affects your site’s organic rankings.
In this article, you’ll learn:
Let’s get started.
As I said, FID tracks how long it takes for the browser to begin processing the first user interaction on a page. FID measures the delay after distinct actions like clicks or taps. Scrolls and zooms don’t trigger this metric.
To pass the assessment a page’s FID should be less than 100ms for 75% of all page loads.
In general, 100ms is an important threshold for users. For example, in his 1993 book Usability Engineering Jakob Nielsen points out the following:
Human perception likely hasn’t changed much since then. And Google also treats 100ms as the line between good and bad FID.
Now, FID tracks the delay after only the first input. Why is that?
Well, first impressions are everything on the web. Users typically don’t stick around if their first attempt to interact with a page is unsuccessful. That’s why keeping a low FID is crucial.
FID is also unique in one other way: it’s a field-only metric.
It requires a real user to provide an input at a specific time. If there’s no input, there’s nothing to measure. And a user clicking on the same button at different times will produce a different result, depending on which tasks are running on the main thread. We’ll talk more about the main thread later in this article.
The first user interaction usually happens between First Contentful Paint (FCP) and Time To Interactive (TTI). However, if you’ve read our article on Total Blocking Time (TBT), you know that TBT also resides in the same area.
So, FID, FCP, TTI and TBT all work together. I know it’s a bit of an acronym overload but bare with me.
Let’s look at each pair separately.
FCP measures when the first piece of content is painted. That could be a picture, video, text, animation, or anything else described in the Document Object Model (DOM).
In other words, FID and FCP measure different things. One deals with responsiveness and the other - with load time. Together, both metrics give you a great sense of the first impression on your website. And as I said, first impressions are crucial.
Also, user inputs happen after the first piece of content is painted. That’s why FID and FCP are inherently connected. Measuring only one of them would give you an incomplete picture of the actual user experience.
TBT is the amount of time during which Long Tasks block the main thread and affect the usability of a page.
Again, we have similarities between FID and TBT.
Both occur between FCP and TTI. And Long Tasks on the main thread can hurt them significantly.
Also, both FID and TBT measure the severity of the unresponsiveness on a page. The difference is that TBT measures it without user input. It simply adds together the blocking time for each Long Task.
This makes TBT primarily a lab metric, unlike FID which is always measured in the field.
On the other hand, FID calculates the delay for each specific case.
TTI is the time it takes for a page to become fully interactive. A page becomes fully interactive when it responds to user input in less than 50ms and event handlers are registered for most visible page elements. Like TBT, TTI is also primarily a lab metric.
Again, FID is a great companion here.
A page might become interactive at any moment. But users can click or tap on the screen way before that. This is where TTI falls short.
After all, what’s the point of knowing when a page becomes fully interactive when the visitor's experience might’ve been ruined before that?
Users don’t care if a page becomes interactive in 6, 7, or 8 seconds. They care if a page was interactive when they needed it to be. That’s why FID fills the gap left by TTI.
By definition, FID measures the time during which the browser can’t respond to user interaction. Once the browser is able to respond, the input delay ends.
So, in order to optimize this metric, we first need to understand why a browser sometimes can’t respond to user interaction on time. The answer is simple:
The browsers’ main thread can get blocked.
You can think of the main thread as the hero that does a lot of the heavy lifting on the web. It’s responsible for crucial tasks, including rendering the page and responding to user interactions.
There’s an awesome video on this topic on Google’s YouTube channel:
For now, it’s important to remember that browsers can’t respond to user interaction while their main thread is busy. This leads to long input delays and consequently - bad FID scores.
You can quickly check your FID with Google’s PageSpeed Insights. It’s one of the first things you see in the “Field Data” report.
And since field data shows how real users experience your site, you want to focus on improving it in the long-run.
You can also use the Core Web Vitals report in Google Search Console (GSC). Open GSC and click on “Core Web Vitals” from the “Experience” menu. After that, you can select from the “Mobile” or “Desktop” reports.
From there, the report shows you all of the pages that have similar issues, like a long FID.
Again, it doesn’t matter which tool you use for the job. The important thing is to always be aware of potential FID issues on your site.
Once you have a general idea of which pages need improvement, you should start looking for specific tasks that cause delays.
The “Performance” panel in DevTools can also help with that. Go to the “Main” section and look for grey tasks with a small red overlay. Those are Long Tasks that have to be broken up.
Additionally, you can group resources by URL and total time to make your job easier.
As you dive into specific tasks, you might find that some longer functions make up most of the delay. In other cases, functions might be run quickly but adding too many of them together in a single task results in a Long Task. Regardless of the reason, splitting Long Tasks helps improve all interactivity metrics.
Here are a few other things to consider when optimizing FID:
Delay or remove non-critical third-party scripts. Third-party scripts can sometimes prevent your own scripts from executing on time. Consider which scripts provide the most value to the user and prioritize them. In most cases, ad and pop-up scripts aren’t at the top of the list;
Use web workers. Web workers allow you to run scripts in the background without affecting the Main Thread. Moving non-UI operations to a background thread is generally a good practice;
Idle until urgent. This approach lets code run during the idle periods or when the resource is requested. You can read this article by Philip Walton for more details on this methodology. Also, check out npm’s idle-until-urgent library;
Minification and compression. Minification means removing unnecessary parts from your code, like comments, whitespace and line-breaks. Compression completely rewrites the binary code within a file. Both reduce file size, making your code easier to execute. NitroPack applies these techniques by default;
A lot of these optimizations require optimizing JS code manually. Obviously, this takes more effort and specialized skills, but the performance gains can be massive.
Besides optimizing JS code, you can help the main thread by rearranging the way resources are fed to it. This is what our proprietary resource loader does.
Our service delays the loading of non-critical resources until user interaction is detected. This helps prioritize resources that matter to your website’s visitors.
We also have a Delayed Scripts feature that lets you specify which scripts you want to load with a delay.
Most importantly, a huge reason why NitroPack produces outstanding speed results is our proprietary resource loader. We don’t use built-in browser techniques. Instead, we created our own resource loader, which rearranges the way resources are fed to the main thread.
While FID is important, it’s far from a perfect metric. Google has already said that a better responsiveness metric is in the works.
Here are a few of the biggest problems with FID:
FID doesn’t track the full event duration, only its delay. The updated metric will likely follow the whole event from the moment user input occurs to when the result of event handlers running is present on the screen;
FID only tracks the delay after the first input. This doesn’t paint a complete picture of the user experience, so Google plans to group events into interactions. The updated metric should capture the full amount of time a user has to wait for a response;
These are just some of the areas for improvement with this metric. For a complete list, check out web.dev’s article on the topic.
Evgeni writes about site speed and makes sure everything we publish is awesome.