How To Improve FID/TBT

Introduction

Among the various new user-centric metrics to measure the speed performance of web pages, First Input Delay (FID) is one of the most crucial components and also perhaps a bit difficult to fully comprehend at first glance. It is a field metric that requires real user data. However, if you want to test the FID of your web page on the lab, fret not because Total Blocking Time (TBT) is one metric that correlates very strongly with FID. In other words, it is safe to say that you can use them almost interchangeably. 

In this article, I will walk you through FID/TBT, methods of measuring them, and real-world examples and applicable methodologies on how you can improve these metrics. For a better perspective, I will share the before and after results of a quick case study on TBT.

Core Web Vitals

First Input Delay is one of the three current metrics in Google’s Core Web Vitals, which is used to measure the load responsiveness of a website.

Google’s Core Web Vitals are essentially the metrics to measure if a website is delivering a great user experience for visitors. The current Core Web Vitals measures three aspects of a website: loading performance, interactivity, and visual stability. It is measured using the following metrics:

  • Largest Contentful Paint (LCP)
  • First Input Delay (FID)
  • Cumulative Layout Shift (CLS)

core-web-vitals

You can read my other articles related to Core Web Vitals here:


You can easily measure your Core Web Vitals by using the latest version of
Google PageSpeed Insights to learn about your scores for the key metrics related to your page speed. The image below shows the six metrics that PageSpeed Insights takes into account to generate your overall performance score. 

core-web-vitals

Does Core Web Vitals Affect Ranking

The short answer is yes. Google has announced that Core Web Vitals will be used as one of the main SEO ranking factors. In other words, websites that score well on metrics of Core Web Vitals will have a better chance of securing a higher position on the search engine results pages (SERPs).
Make no mistake, content is still the king, but improving web vitals metrics is something you have control over.

Page-Experience

What is First Input Delay (FID)

FID refers to how long a webpage takes to become responsive to a user’s interaction. Essentially, slow FID is caused by the web browser being busy with loading and executing all the JavaScripts present on the page. When the browser’s processing thread is busy with the JavaScript, the reaction to the user interaction is put on hold and processed after the JavaScript is loaded and executed. Depending on how many JavaScripts are on your page and how complex and large they are, the delay in reaction to the user interaction can be significant.

For example, suppose you visit a website, and after the page loads, you click on a link, tap on a button, or click “next” on an image slider. FID measures the time it takes for the site to respond to your interaction.

First Input Delay (FID) vs. First Contentful Paint (FCP)

What’s the difference between First Input Delay and First Contentful Paint?

FCP is a metric that measures the time from the moment the page starts to load until the browser paints the first content on your screen.

In short, when you see the first content starting to load, that’s FCP.

Content loading does not mean that you can click on a link or a button or that the browser will immediately initiate any action. Now that falls under the purview of FID.

Why is only the First Input considered

Google only considers the response delay on the very first input due to the following reasons:

  1. First impressions are critical. The first input delay is going to be your first impression of any website. If there is a delay in your very first input interaction with a website, it can shape how you view the site’s reliability and quality.
  2. Most bad user experience related to interactivity is recorded during page load. So, measuring and improving the first input/user interaction can help to significantly improve your site’s user experience and performance.

What is First Input

It is important to understand and classify what exactly is counted as First Input. Generally speaking, any actions from ‘input’ events are included, such as:

  • Clicks
  • Taps
  • Key presses (for example, left/right arrow key to move slider)

Actions such as scrolling and zooming are not considered a part of First Input as they fall under a different category of measurement of site performance.

What is Total Blocking Time (TBT)

TBT is a recently introduced performance metric used in Lighthouse. It measures your page’s load responsiveness to user input. In simpler words, TBT calculates the total amount of time for which your users were barred from interacting with your page due to it being blocked. It is one of the many Web Vitals (a broader category that Core Web Vitals falls under) and can be used in place of First Input Delay (FID) on PageSpeed Insights if field data is unavailable for some reason. 

TBT takes into account the total time between First Contentful Paint (FCP) and Time to Interactive (TTI), where the main-thread was blocked long enough to prevent users from taking any action. The main-thread has the following functionalities: 

  • parsing HTML 
  • constructing DOM
  • executing CSS and JavaScript 
  • processing user events

When any one of the above tasks takes more than 50 ms (milliseconds) to run, the main-thread is rendered “blocked” because the browser cannot interrupt an ongoing task. And when the main-thread is blocked, your page becomes unresponsive to user inputs such as screen taps and mouse clicks. The extra time above 50 ms is counted as the blocking time for each request. All of these blocking times are then summed to generate your page’s Total Blocking Time.

How is FID related to TBT

TBT correlates very well to FID and also captures and highlights issues that affect page interactivity. Both occur between the interval of First Contentful Paint (FCP) and Time to Interactive (TTI). Another point of similarity between these metrics is the fact they both  measure the extent of the unresponsiveness of a page. However, one key difference is that TBT doesn’t take into account user input. 

That said, improving and optimizing the TBT scores of your web pages should positively impact and improve FID for your users because of the strong correlation these two metrics share.

How to Measure FID and TBT

There are multiple ways to measure FID and TBT, as listed below:

  • Google Search Console for FID
  • PageSpeed Insights for FID and TBT
  • Chrome Lighthouse for TBT
  • GTmetrix for TBT

 

Of all the methods, PageSpeed Insights is the easiest to use to know your FID score and other relevant Core Web Vitals. Google Search Console, however, needs you to verify the ownership of your website. Therefore, I recommend using PageSpeed Insights if you want a quick and easy route to accessing your FID score.

One thing to note, though, is that sometimes, you may not see the FID score displayed on PageSpeed Insights immediately. The primary reason behind this is that FID requires real user data (making it a field metric), as mentioned earlier, which makes it difficult to measure in the lab. 

If you choose to run a lab audit on your web pages to find out the TBT, you can use Lighthouse and GTmetrix. Lighthouse calculates the Total Blocking Time by adding up the total blocking effects of the Long Tasks. Any task (such as parsing HTML, constructing DOM, and executing CSS and JavaScript) longer than 50 milliseconds is referred to as a Long Task. This figure is then compared with the TBT score of the top 10,000 web sites. 

More on Tools to measure Core Web Vitals

What is a Good FID/TBT Score

According to Google, the ideal FID score is 100 milliseconds or less. Anything above 300ms is considered poor.

FID

As for TBT, you should seek to keep the number below 300 milliseconds, given an average device and network setup. Here are some thresholds that you can use as benchmarks when measuring the TBT of your web pages:  

  • Good (labeled green in Lighthouse): between the 0 and 300 milliseconds 
  • Moderate, consider improvement (labeled Orange): between 300 and 600 milliseconds 
  • Poor (labeled red): over 600 milliseconds

If the above scores sound too fast and scary for you, don’t fret. This guide will walk you through the strategies that you can use to improve your FID and TBT score.

How to Improve FID/TBT

Here are some steps that you can take to improve your FID score (which should in turn improve your TBT):

  • Reduce execution time of JavaScript
  • Minimize main thread work
  • Reduce the impact of third-party code


For better understanding, here’s a real scenario of a WordPress page with several features and their implementation: 

  • Google Analytics
  • Facebook Pixel
  • HotJar
  • Google Maps
  • Image Lazy Loading
  • YouTube Video
  • Nice looking header slider
  • Chat


All of these are part and parcel many websites. There is nothing erroneous about them. You need analytic and tracking tools like Google Analytics and Facebook Pixel to better understand your audience and what’s working and what isn’t. If you wish to see recordings of viewers, you can opt for HotJar. If your website needs to show your visitors a physical location, then the use of Google Maps is normal. Image Lazy Loading is a feature on many WordPress themes and plugins, and many websites today use a modern-looking slider as the main header.

But these features require websites to load a ton of JavaScripts in the background to function. And unfortunately, these factors are hurting your FID score significantly. 

Now, I am not saying that you cannot use them. They are a necessary part of any website, after all. But there are many ways for you to optimize your website in ways that will help you to achieve your dream FID score!

To illustrate this in a fashion that is very easy to follow, I’m going to demonstrate this to you with a live case study. This way, you can easily replicate the process on your own WordPress website.

Case Study on Improving FID/TBT

Before we dive in, do note that I am only showing how to improve issues that affect your FID score and TBT; the case study is not focused on doing a complete page optimization.

Before I explain in detail about the methodology we will use for the case study, let’s first take a look at the PageSpeed Insights report of the “Before” page we will use for this live case study.

Mobile "Before"
PSI-FID-Before-Mobile
Desktop "Before"

To follow along and perform the methods I will explore in the following sections, you need to install an asset manager plugin like Asset CleanUp / Clearfy / Perfmatters (paid). Even the free version of Asset CleanUp is sufficient. Another option relevant for selectively disable any plugins on specific pages and posts is Plugin Organizer. I will use them to achieve the desired FID score.

You can skip ahead and jump directly to the final PSI results of the “After” page.

Now let’s dive into the exact methodology I will be using to optimize the First Input Delay score.

Deferring Scripts

Deferring scripts is the process by which you can delay the running of JavaScripts while the scripts are being loaded in the background. This way, the scripts won’t be parsed and can run until after the HTML parsing is completed.

Again, this is done on a case-by-case basis; you do not have to defer every single JavaScript on the page. A general rule of thumb is that if the deferral of a JavaScript is unlikely to hinder the page’s load, and if loading it a few seconds later will not affect its functionalities, then it is a good idea to defer the scripts.

Delay Loading Assets

While delaying loading assets may sound similar to deferring scripts, they are different. When you delay loading assets on your web page, it means the asset will only be loaded and run after the initial loading and parsing of the webpage are done. 

Facebook Pixel is one of the most common assets we implement on websites. It can be delayed to load only after the whole web page has been loaded and parsed. Delay loading can not only speed up your webpage, but it can even help you to save money. By delay loading your Facebook pixel, you won’t be retargeting fast bounce users who will leave your site a split second after they enter. Here is my article on how to improve page speed when using Facebook Pixel.

Another example is Facebook Chat, which is another common plugin websites tend to use so that customers can communicate with them via Messenger. As useful as it is, it can significantly affect your FID and TBT scores. Fortunately, it is another asset that can be delayed.

Take a look at the following PageSpeed Insights report after I delayed the loading of the Facebook Chat code snippet.

(PSI Comparison on Desktop – After Delaying Facebook Chat script)

HotJar is another analytics tool with the script that you should delay loading on your website. Take a look at the following PageSpeed Insights report after I delay-loaded HotJar script on my case study site. Please note that for this case study, I made each improvement separately for each page, so the PageSpeed Insights score and TBT score are not displayed as an aggregate figure.

(PSI Comparison on Desktop – After Delaying HotJar)

As you can see above, there are already some decent improvements across the scores, including the Total Blocking Time and Time To Interactive.

By using this method, scripts that are not critical to your initial loading of the site can be delayed. You can not only successfully reduce the initial load time but also improve the FID score of your web page.

Remove Unnecessary Assets

Oftentimes, there are many CSS and Javascripts loaded on every page of your website, even when they are not in use. Some examples are:

  • Font Awesome
  • Emojis


WordPress usually loads emojis and themes and page builders like Elementor are loading a lot of unused icons with Font Awesome. If you are not using them, it is a good idea to avoid loading related CSS and JavaScript files or reduce the icons loaded. This will not only reduce the load time and HTTP requests but will also improve your FID score.

(GTmetrix Comparison on Desktop – Font Awesome & eicons replaced)

Unload Irrelevant Assets

There could be plugins with features you may not be using on all pages, but the problem is, you would still end up with their stylesheet and script files on every webpage! Some common examples are:

  • CSS and JavaScript of Contact Form 7 plugin
  • CSS and JavaScript of slider plugins

 

While there are many other examples, the two mentioned above are quite prevalent, and there’s a high likelihood of you finding them in almost every WordPress website.

Take, for instance, Contact Form 7 plugin. It is an amazing contact form plugin and widely used among WordPress websites. However, it also loads its CSS and JavaScript file on every page, even pages without any forms.

In my case study site, I unloaded the assets of Contact Form 7 on the page that does not use any forms, and the improvement on FID and the page speed are immediate. Take a look at the PageSpeed Insights report below.

(PSI Comparison on Desktop – After unloading CF7 assets)

As you can see, compared to the PageSpeed Insights report of the earlier page, right after I unloaded CSS and JavaScripts of Contact Form 7 plugin, Total Blocking Time (which includes FID metric) goes down to 100ms from the original 160ms. There have been improvements across the other metrics as well. 

The same can be done for slider plugins. By unloading those scripts and CSS from the web pages that are not using any forms or sliders, you can save a lot of performance problems and increase your FID score significantly.

Minifying Assets

Minifying is basically a process to minimize the code to reduce the size and load time of the scripts. This is done automatically using plugins or other software to reduce spacing, comments, and such in script files. A well-structured code with spacing and line breaks is great for developers to read, but web browsers can still process the scripts without them. Hence, by minifying, you are going to make your JavaScript and CSS smaller, which leads to reduced loading times.

Results After Optimization

The following is the PageSpeed Insights report of the “After” page, where I have implemented all the methods I discussed above, including Google Maps, YouTube video and replaced the slider with a static image.
You can see the significant speed improvements as well as the considerable change in Total Blocking Time, which correlates with the First Input Delay score.

As you can see, the improvements are very significant.

Wrapping Up

While it takes some effort to improve the FID or TBT score on your WordPress website, it is a worthwhile time investment. Not only will it make your website rank higher in search results, but it will also significantly improve the user experience of your website. 

Improving your FID and TBT score is one part of the battle to adhere to Google’s standards of a good website user experience. You should also take a look into optimizing and improving your other page speed metrics as reported on PageSpeed Insights. You can check out my articles on How to improve Cumulative Layout Shift (CLS) and How to improve Largest Contentful Paint (LCP) to learn more about these individual metrics.

Page Speed Optimization Course

If you want to learn more about how to optimize page speed, please check out my WordPress Page Speed Optimization Course. Every aspect of this case study is covered in depth in this course, with detailed step-by-step lessons. I will also offer personal assistance to everyone taking the course so that I can guide you along the process.

FREE page speed recommendations for YOUR site

Send me your site URL, and I will personally check your site and give you a few recommendations for free.