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.
So, tricky or not, we better start optimizing it.
In this article, you’ll learn:
Let’s get started.
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:
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.
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.
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.
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.
That’s why FID can only be measured with real users.
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 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.
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.
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.
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.
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 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.
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.
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.
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;
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.
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.
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.
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.