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

Oct 22, 2020 | 6 min

First Input Delay (FID) is a tricky metric to measure.

But it’s also vital for your website’s success. And as part of Google’s Core Web Vitals program, it’ll soon become an organic ranking factor.

Core Web Vitals Visualized

So, tricky or not, we better start optimizing it.

In this article, you’ll learn:

Let’s get started.

What is First Input Delay (FID)?

First Input Delay is the time it takes for the browser to respond to the first user interaction on a page. FID measures the delay after distinct actions like clicks or taps. Scrolls and zooms don’t trigger the FID metric.

If you keep your FID below 100ms, you’re in great shape. In general, 100ms is an important threshold for users.

In his 1993 book Usability Engineering Jakob Nielsen points out the following:

Quote from Nielsen

Source: nngroup.com - “Response Times: The 3 Important Limits”

Human perception hasn’t changed much since then. And Google also treats 100ms as the libe 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 instantly leave and most likely don’t return if a website frustrates them on their first visit. You (generally) only get one shot at a first-time visitor. 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. But we’ll get into that in a bit.

For now, it’s important to know that FID is a field-only metric.

What is Max Potential First Input Delay?

Maximum Potential First Input Delay (MPFID) is the worst-case scenario for the delay between a user’s input and the browser’s response. MPFID depends on the length of the longest task running on the main thread.

Again, this metric computes only the worst-case scenario. It does that by analyzing the main thread.

The main thread does the heavy lifting in terms of rendering a page. Browsers relies on it for a ton of tasks, including responding to user interactions.

The problem is that all JavaScript also runs on the main thread. And Long Tasks (tasks longer than 50ms) can block it from responding to user input.

Main Thread tasks

This is one of the biggest web performance problems today due to the large amount of JavaScript that modern sites have. At NitroPack, we use our proprietary resource loading mechanism to offload tasks away from the main thread.

For a deeper dive into the main thread problem, check out this video from Chrome Dev Summit 2019:

 

But back to MPFID.

If we take the longest task on the main thread and imagine a user clicking a button right when the browser starts executing it, we arrive at the worst-case scenario or MPFID.

MPFID Visualized

In the example above, the browser has to wait until Task One (the longest task) is finished before responding to the user input.

Keep in mind that users can click at any other time. In such cases, a different delay will occur.

Sometimes there won’t be a delay. For example, if the user clicks on a button in between tasks, the browser can respond immediately.

No delay click

That’s why FID can only be measured with real users.

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.

FCP, TBT and TTI

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)

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

Logo triggeting FCP

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

FCP, TBT and TTI

On the other hand, FID calculates the delay for each specific case.

Different FIDs

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.

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 became fully interactive when the user experience might’ve been ruined way before that?

Users don’t care if a page became 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.

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.

FID in PageSpeed Insights

And since field data shows how real users perceive your site, this is what you want to focus on 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 “Enhancements” menu. After that, you can select from the “Mobile” or “Desktop” reports.

GSC Report

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:

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.

How to Optimize First Input Delay

JavaScript is usually the main problem when dealing with FID (and TBT).

Long JavaScript tasks can clog up the main thread, preventing it from responding to user input. That’s why you should start with finding these tasks.

The “Performance” panel in DevTools can 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.

DevTools Performance panel long tasks

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

You can try to implement these optimizations by hand. It’s hard and time-consuming, but it’s worth it. Especially if you have problems with your site’s interactivity metrics (FID, TBT and TTI).

On the other hand, you can also use a service to quickly solve the issue once and for all.

NitroPack and JavaScript Optimization

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

As I said, our service minifies and compresses code files. It also 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.

Delayed Scripts feature in NitroPack

Most importantly, a huge reason why NitroPack produces outstanding speed results is our proprietary resource loading mechanism.

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.

NitroPack Resource Loader

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.

But don’t take my word for it. Test NitroPack and see the results for yourself. Our free plan doesn’t expire or require a credit/debit card, so you can see the full power of NitroPack without risking anything.