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 a ranking factor.
So, tricky or not, we better start optimizing for it.
In this article, you’ll learn:
What First Input Delay Is
Why It’s Crucial For Your Website’s Success
What Maximum Potential First Input Delay Is
3 Ways To Check For Problems With Your FID and MPFID
How FID Fits In With The Other Web Performance Metrics
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:
“0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.”
Source: nngroup.com - “Response Times: The 3 Important Limits”
Human perception hasn’t changed much since then. And Google also treats 100ms as the border 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 will instantly leave and most likely won’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.
Of course, other input delays can also hurt the user experience. Improving your FIDs isn’t an excuse for neglecting all other delays.
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.
That’s the reason Max Potential First Input Delay exists.
Maximum Potential First Input Delay (MPFID) is the worst-case scenario for the delay between a user’s input and the response from the browser. MPFID depends on the length of the longest task running on the main thread.
You can see your MPFID under the “Performance” section of the Lighthouse report.
Again, this metric computes only the worst-case scenario. It does that by analyzing the main thread.
If you don’t know what the main thread is, here’s the TL;DR:
The main thread does the heavy lifting in terms of rendering a page. The browser relies on it for a ton of tasks. Including responding to user interactions.
Okay, 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 be measured only with real users.
At the same time, MPFID gives you valuable information without needing a real user.
You can easily check your FID with Google’s PageSpeed Insights.
It’s one of the first things you see in the “Field Data” report.
You can also use the Lighthouse audit in Chrome to check for MPFID.
Go to a page you want to analyze, right-click and select “Inspect.” After that, click on the “Lighthouse” button.
Select what you want to test for and let Chrome do its thing.
The “Performance” category has information about your MPFID.
Finally, you can use Google Search Console (GSC) and its Core Web Vitals report.
Open GSC and click on “Core Web Vitals” from the “Enhancements” menu.
After that, you can select from the “Mobile” or “Desktop” reports.
If there’s a problem with your FID, these 3 tools will help you find it.
From there, it’s all about digging deeper into specific problems.
However, most websites don’t have a particular issue that only affects FID. A lot of the best practices for improving website performance in general will also help with FID.
If you want to start optimizing for FID right now, check out this awesome article by the Lighthouse team.
For now, let’s dive deeper into FID and the other web performance metrics.
However, if you’ve read our article on Total Blocking Time (TBT), you know 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.
We’ll 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 DOM.
So, 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.
So, looking at both gives you a clear picture of how much the interactivity of a page was affected by Long Tasks.
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.
FID won’t become a ranking factor until 2021. Most people won’t worry about it until then.
If you optimize for it now, you’ll get a nice head start on the competition. Plus, you won’t have to think about it when 2021 rolls around.
But optimizing your FID isn’t enough. You’ll also need to think about the other two parts of the Core Web Vitals program.