First Input Delay (FID): What It Is & How to Optimize It

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:

• What First Input Delay (FID) is and why it’s important;

• How it fits in with the other page speed metrics;

• How main thread blocking time affects FID;

• How to measure and debug FID;

• Proven optimization strategies;

• Why this metric will change soon.

Let’s get started.

 

What is First Input Delay (FID)?

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 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.

FID and Other Web Performance Metric

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.

FID and First Contentful Paint (FCP)

Is First Contentful Paint the same as First Input Delay?

While this is a common question, FCP and FID are two different metrics.

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.

FID and Total Blocking Time (TBT)

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.

So, looking at both gives you a clear picture of how much a page’s interactivity is affected by Long Tasks. And because FID and TBT are so similar, both are usually affected by the same JavaScript issues.

FID and Time To Interactive (TTI)

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.

FID and the Main Thread

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.

Unfortunately, the main thread is also overworked. The growing complexity of the web results in websites using more and more resources, including CSS and JavaScript, both of which run on the main thread.

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.

Measuring First Input Delay

 

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.

If you’re comfortable with using JavaScript, you can also experiment with two other tools:

• The web vitals JavaScript library;

• Chrome’s User Experience Report (CrUX).

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.

Debugging FID and Finding Long JavaScript Tasks

Once you have a general idea of which pages need improvement, you should start looking for specific tasks that cause delays.

Long JavaScript tasks can clog up the main thread, preventing it from responding to user input. One way to find these tasks is to test a page with PageSpeed Insights and click on the “Avoid long main-thread tasks” audit.

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.

Other Ways to Improve FID

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;

• Reduce unused CSS. While JavaScript is usually the main villain, CSS also blocks the main thread. By reducing unused CSS, you lower the total number of bytes that have to be downloaded. More importantly, you ensure browsers can start rendering the page faster since they have fewer operations to perform.

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.

NitroPack's Resource Loader

Two of NitroPack’s biggest advantages are the way it handles resource loading and JavaScript execution.

• 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.

• We do this to take advantage of modern CPU’s multi-core nature by offloading tasks away from the main thread. And as I already mentioned, freeing up the main thread is the most important benefit of JavaScript optimization.

What’s Next for the FID Metric?

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;

• Because of these shortcomings, FID is currently too forgiving. It doesn’t incentivize people enough to fix important issues like heavy JavaScript usage. The Chrome team even admits this in their documentation.

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.