First Input Delay is an essential metric to track and improve on your web page.
Delivering a fast user experience to your website visitors is critical to your site’s success. But how do you know whether your site is achieving the right speeds?
That's where First Input Delay (FID) comes in.
In this post, we’ll explain what FID is, how to measure it and what a good FID score is. We'll also reveal some ways you can optimise your FID for better results.
Let's dive in.
What is First Input Delay (FID)?
First Input Delay (FID) is a web performance and user experience metric that tracks the time from when a visitor first interacts with a web page to the time when the browser starts processing the interaction. This is sometimes called Input Latency.
First Input Delay measures the amount of time in milliseconds (ms).
To put it in simpler terms, FID is the delay between the user interaction e.g. when you click or tap on something like a link or a button, to the time the browser responds to your action and starts processing it.
Think of it like measuring the time from when you ring someone’s doorbell to them answering the door.
The important thing to know about FID is that Google uses it as a ranking factor. It’s one of the Core Web Vitals, which are the metrics Google uses to determine the quality of your site’s user experience and, in turn, its page rank.
More than that, improvements to site performance and user experience generally lead to increased conversions, sales, and ad revenue. By addressing your FID, you can overcome that feeling of frustration that users may experience while your page is loading.
That's what makes First Input Delay one of the most exciting web performance metrics - it is one of the pure Real User Metrics, not a lab metric. It cannot be simulated in a lab test – it requires real user input in order to be measured. FID measures the actual experience of real users who enter your page.
There are a few things that are matter when measuring First Input Delays.
FID only measure finite interactions
The events that count as user interactions must be discrete, or finite. That means it can only be something that has a clear beginning and end point, like tapping a button, clicking a link, or selecting a checkbox.
Continuous types of user interaction, like scrolling your web page or zooming, can’t be properly measured using this metric because there’s no response expected from the site itself - and the goal for First Input Delay is to measure how responsive a site is while it’s loading.
To summarise, user input includes clicks not scrolls.
FID only measures the first user interaction
The first time a user interacts with your page is their first impression, and first impressions are everything. This determines how they experience and perceive your web performance (and therefore whether they will stay or go).
Most of the blocking of the browser’s main thread happens in those first moments of a page’s lifecycle, because that’s when critical resources load.
By measuring First Input Delay, you can make sure those critical resources are loading fast and don't result in your website feel clunky, slow and unresponsive.
First Input Delay is different from Time to Interactive
Time to Interactive (TTI) is another helpful web performance metric and can be confused with First Input Delay.
TTI measures the time it takes for a page to be fully interactive, i.e. when there’s useful content already rendered on the page, user interaction is processed within 50ms and event handlers are registered for most page elements.
First Input Delay is not the same. FID is used to track the user input that happens before the page is fully interactive. So, a user may click on a link that appears before event handlers are registered for most page elements, and First Input Delay allows you to capture those early interactions.
The Cause of First Input Delay
A few different factors can affect the First Input Delay metric:
Large bundles are typically caused by excessive third party dependencies or when code is included that is not needed by the current page.
This problem is caused by poorly optimised code.
Speed and processing power of the user’s device
This may have an impact on your FID, but you can’t control that.
What is a good FID score?
Remember that FID is measured in milliseconds (ms) of time, so the less you score, the better. You don't want long input delays.
According to the FID thresholds in PageSpeed Insights:
- FID of 100ms or less is good
- FID of between 100-300ms needs improvement
- FID above 300ms is poor.
According to research by NN Group, 0.1 second is about the limit for having the user feel that the system is reacting instantaneously. So, try and keep your FID under 100ms.
In some cases, your FID might be under 100ms and scoring as "good" but the page may still feel unresponsive. That's because the browser still needs to run the task associated with the user input, and that's not measured by FID.
How to measure First Input Delay on your page?
Try these tools to measure your First Input Delay:
- Chrome User Experience Report through BigQuery (origin level) or the CrUX API (both the origin and URL level)
- Google’s PageSpeed Insights
- Search Console (Core Web Vitals report)
They all measure FID along with lots of other key metrics. So the one you choose depends on the other performance metrics you want to track, and your preferred way of measuring.
Let's talk through how to use the tools to measure FID.
Chrome User Experience Report
The Chrome User Experience Report provides user experience metrics for how real-world users experience your website.
The Public Google BigQuery project aggregates user experience metrics by origin, if known by Google's web crawlers, and split across multiple dimensions. To access BigQuery, you need a Google account and a Google Cloud Project. Google has a step by step guide and handy guided tour of how to query the project.
Alternatively, the CrUX Dashboard on Data Studio can be setup by web developers to track an origin's user experience trends.
To get started, go to g.co/chromeuxdash where you can provide the origin for which the dashboard will be generated.
On the dashboard, you can set up the origin's monthly Core Web Vitals performance. Core web vitals metrics are the most important UX metrics that Google recommends you focus on, including First Input Delay.
One of the easiest tools to use to do an input delay test is Google's PageSpeed Insights.
This is a free tool that tests your site’s performance in lots of ways and shows how your site scores with some key metrics, including First Input Delay.
Remember, First Input Delay requires a real input event. But so long as your site has recently had user interactivity, you should be able to find your score on PageSpeed Insights. Google denotes this score as field data because it's based on actual user interaction, not lab tests.
Simply enter your site’s URL into the text field and click on Analyze.
Once the tool has finished analysing your page, you will be shown the results. Your site gets an overall score, but it's the Field Data section that you want to focus on.
This shows how real users experience your site, and is where you will find the First Input Delay (FID) metric.
Then, go to Opportunities to see suggestions for optimising your page and improving your scores.
Google Search Console
You can also use the Core Web Vitals report in Google Search Console (GSC) to measure FID.
Open GSC and go to the Experience menu, then click on “Core Web Vitals”.
You can choose to measure FID for mobile users or desktop - simply select from the “Mobile” or “Desktop” reports.
The report shows you all of the pages that have similar issues.
Once you've measured your site's First Input Delay, how can you optimise it?
Take a look at the below tactics. A lot of these optimisations mean you need to optimise JS code manually, which requires a skilled web developers in most cases. But the performance gains are well worthwhile and your user experience will be much improved.
The result? A lower First Input Delay.
A quick and simple way to minify your code is to use an online tool like Minify Code or get your web developer to help.
The solution is to break these tasks up into smaller ones so user input can be processed between them. Try to keep your tasks under 50ms.
The best way to this is with code splitting, which is where you break up and load smaller and necessary pieces of code at a time, rather than one large file all togeher. Tools like Webpack will let you do this.
Reduce the impact of third-party code and non-critical scripts
Too many third-party scripts, such as tags and analytics, can delay the execution of your site’s own data.
So, in a bid to optimise your First Input Delay score, reduce the impact of third-party code, remove any non-critical third-party scripts and defer those that you cannot remove.
How do you decide which scripts are most important?
Consider which scripts play an important role in your site’s UX. Prioritise loading whatever offers the greatest value to users first.
Start by removing or delaying ads or pop-ups that aren’t necessary. Also, look under the Opportunities section of your PageSpeed Insights report for recommendations. It will list specific files and tasks that could be blocking your main thread.
Use Idle until urgent
Conceived by Philip Walton from Google, Idle until urgent provides a smart way to evaluate your code so that input delay is minimal.
The strategy combines two popular approaches to code evaluation:
- Eager evaluation: All of your code is run right away, resulting in a page that loads for a long time until fully interactive, then runs smoothly.
- Lazy evaluation: Your code is run only when needed.
Idle until urgent lets you run code during completely idle periods to use the main thread to the fullest extent possible. But it also guarantees that any urgently needed code is run immediately.
This is a great way to improve your First Input Delay. Because code execution only happens during idle periods, you are minimising the main thread blocking time.
Read this article by Philip Walton for more on this approach.
Use web workers
Web workers allow you to run scripts in the background without impacting the main thread.
Moving non-UI operations to a background thread is good practice for web developers.
A positive first impression goes a long way with your website visitors and you only have one chance to get it right. Investing some time and effort in measuring your site's First Input Delay and optimising your score will help you improve your user experience in the long run.