What is First Input Delay (FID)? How do I resolve FID issues?
What We’ll Cover:
- What is first input delay?
- Different ways you can track FID
- How to solve first input delay issues
First impressions are everything—especially when it comes to your website
That’s why page speed is vital to your website’s user experience and to your SEO rankings.
While Google Search Console no longer measures page speed, the new Core Web Vitals report does — It uses three metrics: largest contentful paint (LCP), cumulative layout shift (CLS), and first input delay (FID).
First input delay was introduced in May 2018 by Philip Walton, a senior developer at Google.
What is First Input Delay?
First input delay, or FID, evaluates how responsive your page is.
It measures the time between when a user first tries to take an action on your page (like clicking a button) and when the page is able to respond.
A good FID is under 100 milliseconds. FID between 100 and 300 milliseconds could use improvement but isn’t terrible.
Anything over 300 milliseconds definitely needs to be fixed.
We’ve all visited websites where we click a button or submit a form, to seemingly no response from the site. It can take seconds to get to the next page—that’s hours in digital time.
Users may leave your site out of frustration. And that, in a nutshell, is first input delay: a measure of user frustration with your page.
What Causes First Input Delay (FID)?
This means there is content visible on the page, but the browser isn’t actually able to respond yet.
The same page can even see variances in FID, because the length of the delay depends on whether the main thread is idle or busy at the first user input.
If the user happens to click at a time when the main thread is idle, the page will be able to respond. But if they click even a second later, the main thread may be busy again, causing a long first input delay.
How to Track First Input Delay
Because the length of first input delay has so many variables—whether a user interacts with your page, when they interact, and what exactly they do—its tracking and analysis are unique compared to other metrics.
It’s a user-centric performance metric that can only be measured “in the field”: it requires real user interaction.
The new Core Web Vitals report will give you the information you need, as it measures real-world experiences.
Just open the Google Search Console and go to the Enhancements menu. Click on Core Web Vitals and select mobile, desktop, or both.
The code will loop through interaction events and add a callback to each one to measure the FID. You can send the information to Google Analytics or your tracking program of choice.
What about PageSpeedInsights (PSI)? It may not always have data available for first input delay.
PSI uses the Chrome User Experience Report (CrUX) dataset to look up this metric. If it isn’t available in CrUX, you’ll see the message “The Chrome User Experience Report does not have sufficient real-world speed data for this page.”
Likewise, the Lighthouse tool in Chrome is a lab metric tool, and won’t give you field metrics.
You can use the lab metric total blocking time (TBT) as a substitute for FID—the methods for improving both metrics are similar.
How to Fix First Input Delay
If your first input delay is longer than 300 milliseconds, Core Web Vitals will show your score in red. That’s your cue to get to to work.
What can you do about it? Here are some of the common problem areas and fixes.
Remove or optimize third-party scripts
Third-party scripts like social media buttons, analytics, and advertising can slow down your page. It’s always best to remove any that you don’t absolutely need.
For scripts you need, you can code-split them into smaller chunks that can be fetched only when needed (aka “lazy loading”). Or, defer scripts the page doesn’t need for above-the-fold content or critical content, using defer or async.
One option is to break long-running tasks into smaller tasks (less than 50 ms). This allows the browser to take a break and handle any user inputs.
Minimizing unused polyfills can also speed up execution. Polyfills are a part of the code that’s needed in order for your site to work in older browsers.
Keep the main thread idle
You can also run long tasks off the main thread. This will keep the main thread idle—and therefore able to respond to user inputs.
Transferring your data to a Web Worker is the easiest way to do this. The cost of transferring the data is small, while the payoff—keeping the main thread idle—is huge in terms of your page speed analysis.
First input delay is an important metric for measuring page speed because it is based on real-life user data. It will tell you how your page behaves in the real world—and how your user experience could be suffering. Get a handle on first input delay, and you’ll reduce user frustration and improve your SEO rankings.