First Input Delay (FID) is one of three metrics comprising the Core Web Vitals that have become a stronger signal in the Google search engine ranking algorithm in the summer of 2021. The other two metrics are Cumulative Layout Shift (CLS) and Largest Contentful Paint (LCP), also covered in this guide. FID measures the time from when a user clicks on a button or a link to when the browser begins processing the user’s input. Have you ever been frustrated waiting for a web page to take your desired action after you click? If so, it means that your browser is busy processing code from the website before processing your input.
FID differs from the other two web performance scores because it requires real user traffic on a web page to calculate a score. It means FID scoring relies on RUM (Real User Monitoring, also known as a “field” measurement) instead of emulated testing (also known as a “lab” measurement) to diagnose and troubleshoot the performance of the user interactivity. Fortunately for web developers, the Total Time Blocking (TBT) is a proxy metric for FID and is measurable in a lab with WebPage Test (covered later in this article). TBT measures how long the browser’s main thread is blocked, preventing user input from processing. Due to the FID score’s multiple shortcomings (covered later in this article), Google considers introducing a new and improved measurement for user responsiveness to replace FID in the future.
FID refers to the interactive responsiveness of a website. It starts with the user’s first interaction with a web page. Measured in milliseconds, FID is the time your browser takes to initiate processing a user input such as:
This input delay happens when your browser fails to respond immediately to a user request because other longer tasks occupy its main thread.
FID is controversial because it doesn’t include all types of user input (for example, it excludes scrolling) and doesn’t measure the entire processing time of user input (only the delay until its start). Most web developers would prefer a score calculated in a lab environment to overcome the logistical and practical problems in gathering the data necessary to improve a web page before it’s publicly launched.
These shortcomings have promoted Google to plan improvements for the FID score to:
There isn’t a firm timeline for introducing this new metric yet, but this Google article describes the improvement plans.
Firstly, it must be clear that TBT (Time Blocking Time) is not a Core Web Vital metric but serves as a proxy for FID. It measures the amount of time (in milliseconds) that a browser's main thread is blocked, making the page unresponsive to user input.
The table below shows typical tasks processed by a browser’s main thread while displaying a web page.
Any task that takes more than 50 milliseconds to execute in the main thread is considered long, which is why TBT measures the total excess time beyond the first 50 milliseconds of a task’s execution time. For example, in the diagram below, the total execution time is 560 milliseconds even though the blocking time is only 345 milliseconds (the portions of the tasks that take more than 50 milliseconds to complete).
People prefer using fast and responsive websites. Conversely, slow websites make users leave, interrupting a potential e-commerce transaction or reading an article. Google updated its search engine algorithm between June and August of 2021 to rely more heavily on the Core Web Vitals as a ranking signal. This change means that all other (100+) ranking signals being equal, a website that is slower to respond to users’ input would rank lower on Google’s search engine’s results page than a more responsive page.
Mercado Libre (translates to “free market”) is a publicly traded company founded in 1999 in Argentina with over 15,000 employees who operate the largest e-commerce and payment platform in 18 Latin American countries, including Brazil and Mexico.
The web performance engineering team at Mercado Libre improved a poor FID by focusing on TBT as a proxy and by using WebPageTest to measure it, resulting in a case study published by Google. They had noticed that their “product details” page spends a lot of its loading time on the analytics module, as shown in the WebPageTest waterfall screenshot below, thereby delaying the loading of the core application functionality.
A good FID indicates a responsive web page, therefore, a positive user experience. The website administrators should strive for an FID score of less than 100ms. The RAIL model quantifies the human perception of a rapid response and determines 100 milliseconds as the tolerable threshold in user experience.
Consider a blog article hosted on Themarkup.org as the first example of a page optimized for performance. In this case, Total Blocking Time (TBT) is 50 milliseconds which means that the FID score would be favorable. At this link, you can find the archived results of the test conducted on WebPage Test, producing the screenshot below.
As you go to the WebPage Test report link to view the archived results, scroll down the page, and at the end, you will find a waterfall diagram displaying the request-by-request loading behavior of the web page. A fast web page shows a chart with small bars, which means quick rendering and fewer resource requests, as shown in the following screenshot.
At the time of measurement, the business news of theguardian.com scored a TBT of 1344 milliseconds which means that the FID score would be relatively poor. It suggests that multiple tasks block the page and delaying user interaction. At this link, you can find the archived results of the test conducted on WebPage Test, producing the screenshot below.
Go to the link provided above to view the archived WebPage Test results and scroll down the page. You will find a waterfall chart at the end of the page, which is the graphical representation of the resources loaded by the web browser. The following image shows which resources were causing the web performance bottlenecks causing a poor FID score.
First Input Delay is different from LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift) and Total Blocking Time (TBT) because it measures the real user experience, which is why this measurement requires actual users to engage with the web page.
This user-centric metric can only be measured in more detail with the help of field monitoring tools introduced below.
To measure FID using this tool, enter your website URL in the box shown below.
As you can see in this image, the FID score of the web page used in this example is 30ms, which is good. It means this website is responding quickly to user input.
Click on “Generate Report,” and Lighthouse will start measuring your site’s performance.
After some time, you can see a report similar to the following image.
Go to your site’s Google Search Console and examine each web property for a detailed Core Vitals assessment.
Check the FID score for both desktop and mobile. The following example is for mobile showing that 58 pages are affected by a poor FID score, as captured in the screenshots below.
All of the tools above help you isolate the web pages on your website that suffer from a poor FID so that you can begin a journey to improve them.
Although you cannot measure FID using lab tools like WebPageTest that emulate transactions, you can measure TBT as a proxy for FID.
Below are the steps to measure TBT on WebPageTest.
1. Go to www.webpagetest.org/webvitals
2. Enter the web page URL you want to test.
3. Click on Start Test and wait a couple of minutes to get the final results.
In the following image, you can see the Total Blocking Time of the respective page is 50 milliseconds, which suggests that the FID score would be good.
Below are the key reasons for poor FID, along with the best possible solutions.
Below are the key reasons for poor FID, along with the best possible solutions.
Consider the example of thegaurdian.com, and you can see a high TBT (indicating poor FID) in the Web Vitals section of the WebPage Test results report, as shown in the screenshot below.
Scroll down the respective page, and you will see the WebPage Test waterfall at the end. Next, click on the “Long Tasks” (see the screenshot below), which will direct you to the Chrome Dev Tools performance panel. You can view detailed results showing which tasks interrupt the page loading and delay the user interaction, causing low-score FID.
Generally, the long tasks are marked with a striped red background, as shown in the following screenshot. These long tasks in the performance panel identify the potential areas for improvement in your FID score.
Minimize the use of polyfills (pieces of codes required for web pages to work correctly on the older browsers) on your web page. Remove the outdated polyfills (for browsers that are no longer in use) and keep only the necessary ones.
Content visibility is one of the most impactful CSS properties that control whether an element renders all of its contents or not. As a result, it helps improve the loading of web pages by enabling the users to skip the rendering work until required.
If you haven’t conducted this exercise in a while, you should make a list of all third-party scripts used on your website and check with your marketing team to ensure they are still needed. You may find unused scripts never removed.
You can usually delay the loading (or lazy-loading) of most of these scripts since your website’s visitors won’t use most of the heavy services (such as chatbots) while the page is still loading.
As an additional resource, this Google guide will give you detailed, actionable steps to improve your site’s FID score.
First Input Delay (FID) measures the real-world responsiveness of a web page and is one of three components of Google’s Core Web Vitals that has become a stronger signal in Google’s search engine ranking algorithm in the summer of 2021.
The downside of FID is that it doesn’t measure all user input (such as scrolling) and can’t be measured in lab testing, which is why Google is planning to improve or replace it in the future. The best way to measure FID in the lab is to rely on its proxy metric known as Total Blocking Time (TBT) that WebPageTest can freely measure.