Chapter 2:
First Input Delay
October 5, 2021
15 min read
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.
A browser’s processes (a process can have multiple threads) are responsible for displaying and controlling the browser, rendering a website’s content, and processing user input, among others. The thread that runs all JavaScript on a web page is considered the “main thread.” The main thread is also responsible for processing the events produced based on user input (such as a click) via its “event handler.” A long-running JavaScript code keeps the main thread busy, blocking the event handler.
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.
They managed to reduce the page’s maximum potential FID from 1,710 milliseconds (close to a frustrating experience) to 200 milliseconds (considered rapid for an e-commerce page) by removing the unnecessary JavaScript in their page’s analytics module and by splitting and optimizing the remaining JavaScript (techniques explained later in this article). Reducing FID by close to 90% has helped Mercado Libre retain customers longer on their platform and increase sales since shoppers who routinely experience long page load times abandon the purchasing process and visit competing websites.
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.
The main culprit for a low FID score is heavy JavaScript execution taking more than 100 milliseconds to run. JavaScript authored on the web page can cause a degradation in responsiveness as much as linked third-party scripts that load onto the page (such as scripts used to display ads).
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.
It usually happens because of large JavaScript bundles, poorly optimized code, failure to remove unused scripts, or coding mistakes.
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.
If your URL is affected by JavaScript issues, Google PageSpeed Insights will show the warnings and suggestions in the “opportunities and diagnostics” section, as shown in the following screenshot. The items under the diagnostics section will list the main problems causing a low FID score. Click here to see a live example from the vogue.com website.
In the screenshot below, you can see the expanded section “Reduce JavaScript Execution Time,” pinpointing specific JavaScript code taking too long to execute.
Finally, Long Tasks API can also help advanced users detect long JavaScript tasks as a programmatic alternative to the methods described above.
A faster server can help improve the Core Web Vital score by enhancing your website’s load speed. However, the page’s responsiveness will still be slow because the browser’s main thread will still get blocked by the long JavaScript tasks. The ultimate solution is to remove unused JavaScript and optimize the remaining code.
A practical solution to reduce JS execution time is to defer JavaScript execution. With this approach, your browser will load the JavaScript files only after completing the page’s rendering. You can either defer Javascript manually or by using a plugin on a platform such as WordPress. For manual deferring, Identify the JS scripts you want to defer and add the defer attribute as shown below.
“Async” and “Defer” are both optional attributes for the HTML <script src="..."> tag used to delay the loading of JavaScript. The difference is that “Async” executes as soon as possible while “Defer” waits until just before the DOMContentLoaded event, so it’s less likely to interfere with user input during load time.
You can split the long-running JavaScript tasks into smaller ones that run when required and do so in less than 50 milliseconds. In this way, the browser’s event handler will process user input during the intervals between processing the shorter JavaScript tasks.
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.
Use the browser cache to save the load time and network traffic because the stored local copies of the static assets take less time to load the content. Getting a resource from your local cache is always faster than loading it over the internet. Caching allows your browser to run quicker even through the JavaScript loading tasks, improving the FID score.
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.
Suppose your website contains heavy third-party codes or scripts such as advertising, analytics, chatbot, or social media buttons. In that case, it can have the same effect as your authored JavaScript code in degrading the FID score.
Web developers understand the JavaScript that they have implemented better than the ones provided by third-party, which is why every third-party script should be individually reviewed and vetted.
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.