Our series of articles on Google Core Web Vitals discussed First Input Delay (a field-only metric) that quantifies the web page interactivity. This real-user web performance metric helps track and improve the delay in user interactions. Unlike other web performance metrics, Cumulative Layout Shift (CLS) and Largest Contentful Paint (LCP), it takes real user’s interaction with a web page to calculate FID. 

FID score is not measurable with lab tools like WebPage Test. Therefore, we have to rely on Real user monitoring (RUM), also called field measurement, instead of synthetic monitoring (known as lab measurement). That’s why you cannot see FID in core web vital reports in lab testing tools. However, Total Blocking Time (TBT) can be used as a proxy user-metric for FID. 

What is TBT? 

The Total Blocking Time (TBT) metric of the WebPage Test can closely estimate the FID score. It essentially measures how long a browser takes to respond to an input event.

“TBT is a sum of time periods between First Contentful Paint (FCP) and Time to Interactive (TTI) when the processing time of a particular task exceeds 50ms, and it blocks the main thread.”

TBT helps find the long tasks which block the main thread and delay the browser’s response to user input. User interaction must be processed within 50ms. 

Note:

TTI corresponds to when a web page becomes fully interactive.

Defining Long Tasks & Main thread 

Every task executed in more than 50ms can block the main thread (where a browser handles layouts, parse HTML and CSS, build DOM and render and paint the display). It slows down the browser, leading to an unresponsive web page and causing a delay in responding to user input. See the image below. 

How idle tasks affect user’s input response
Source: web.dev

This main thread, also called the user interface (UI) thread, is the last to finish execution, and its blocking means a bad user experience. 

According to MDN Web Docs, a browser typically uses a single thread to run all JavaScript functions, perform layout and reflows, etc. Unfortunately, the long-running JS code occupies the main thread and blocks the event handler, resulting in an unresponsive page. 

Note:

Every millisecond after the initially calculated 50 milliseconds for every long task in the main thread is counted as total blocking time. 

Let’s understand this with an example. 

The following image shows the main thread timeline with different task durations (in milliseconds). 

Main Thread Timeline (tasks duration)

Now, see the red sections below denoting the TBT calculation for the tasks in the main thread. Every red box corresponds to the TBT per Long Task.  

Main Thread Timeline (task blocking time)

The total blocking time, in this case, is 345ms.

TBT Score Threshold:

You are good to go if your site’s TBT score falls under 300 milliseconds. Your website performance needs improvement if it scores between 300-600 milliseconds. However, if it crosses the threshold of 600milliseconds, your site is in a danger zone. Take appropriate and immediate actions to fix all poor-scoring issues if you do not want Google to boot your site down. 

TBT as a Lighthouse Performance Metric

Total blocking time is one of the critical user-centric speed metrics in Google Lighthouse. As a result, it has been added in Google’s performance score update that comes with the release of Lighthouse 6, including two Core Web Metrics – LCP and CLS.  

TBT constitutes 25% of the overall speed performance score of a website in Lighthouse 6. 

In the following table, you can see the comparison between Lighthouse versions 5 and 6. 

Source: web.dev  

You need to focus on these metrics because the faster a page loads, the higher it will rank in search engines and more conversions and revenue you will receive.  

The order of these metrics in this new performance score weighting formula is according to their appearance as the page loads.

What does it mean? 

Performance score calculation in Lighthouse summarizes the speed of a web page in phases. 

Let’s understand this with the following table. 

Source: web.dev

Hot Tip:

Explore your site’s speed performance with Lighthouse Scoring Calculator.

RAIL Model – User perception of performance delay

The RAIL model measures how web users perceive performance delays. It quantifies the human perception by breaking down the user experience into direct actions like screen tapping, scrolling, and loading. 

The following image shows the four primary elements of this performance model that significantly affect the total blocking time metric.    

   Source: web.dev

Note:

The TBT threshold of 50ms comes from this RAIL Model. 

TBT displayed in Lighthouse:

As you conduct a Lighthouse audit, it will generate a report like this to see key web performance metrics, including TBT. 

What causes poor TBT?

As you can see in the image below, it is clear that the main reason for the blocked main thread is JavaScript execution – be it loading the heavy files, processing large bundles or rendering, etc. 

Therefore, for easy understanding, we have divided the leading causes of slow TBT as; 

1. Lengthy JavaScript Execution
2. Third-Party Scripts 

How to measure TBT?

You can measure this metric using lab and field monitoring tools, but you have to rely on Lighthouse Audit for a detailed report. 

Reason? The other web performance measuring tools will only give you the main thread’s block time. At the same time, developers can get all vital information like what tasks cause that blockage and what they need to do to improve the page’s quality and speed performance. 

So, here, we will briefly explain how these tools work for TBT measurement. But remember that only Chrome DevTools allows you to dive deeper into details about this metric.

Let’s take a look.

WebPage Test

1. Go to WebPage Test
2. Insert Target URL 
3. Click on Start Test 

Wait for a few seconds, and you will get a detailed report, including the TBT score.

Go to the Web Vitals Tab, and you will see the following screen. 

Click Total Blocking Time, and you will be navigated to the waterfall diagram showing different elements related to website performance. It visualizes request-by-request page loading behavior.

See the archived results here.

Note:

You can view more details about Total Blocking Time in the Chrome DevTools Performance panel.

PageSpeed Insights

1. Go to PageSpeed Insights 
2. Insert Target URL 
3. Click on Analyze 

Wait for a few seconds, and you will get the results as shown in the following video. 

Lighthouse Chrome DevTools 

Lighthouse audit is the best solution to detect TBT score and examine long tasks affecting the page loading speed and slowing this metric down.   

Here we are using The Markup’s article as an example.

Open your target web page.

Right-click and select Inspect
(Alternatively, you can press Ctrl + Shift + I or F12 to open the Developer Tools)

Go to the Lighthouse at the top-right corner. 

Now, click on Generate Report. 

Check the Opportunities and Diagnostics section for the main thread work.

Hit it, and you will see what’s potentially blocking the main thread and delaying the browser’s response to user input. 

Inspecting long tasks in the main thread 

You need to understand what causes poor interactivity and detect the occurrence of long tasks during the page load, thereby blocking the main thread. 

You can determine the long tasks in two ways:

Using “Avoid long main-thread tasks” in the Lighthouse report

1. Generate Lighthouse Audit report
2. Go to the Diagnostics section 
3. Open Avoid long main-thread tasks

It enlists all the instances where the Lighthouse tool detected the long tasks, potentially blocking the main thread. See the image below. 

Pro Tip:

You can select “TBT” as shown in the following image, and you will directly get your required information about long main thread tasks and what main thread work needs optimization to fix input delay.

Viewing “the original trace” 

1. Generate Lighthouse Audit report
2. Click the View Original Trace button

Wait for a few seconds as the profile loads, and you will see a detailed time of the page load as shown below. 

Make sure you have checked the Web Vitals setting to see the “Long Tasks.”  

In the image below, you can see what the main thread does and at what times.

Blue boxes with lines denote long tasks that load faster than 50ms, causing no trouble to main thread processing. On the other hand, the red-flagged boxes with red stripes are long tasks causing poor TBT and need to be fixed.

Hover over any red sections, and it will tell you the non-responsive time of that particular task during the web page loading process, blocking the main thread, resulting in input delay. 

As you detect the long tasks taking more than 50ms to process, you can fix it for improved TBT and, ultimately, the FID score of your website. 

Find long tasks that need optimization:

Find and optimize the long tasks to improve the TBT score. The following image from Chrome DevTools shows long tasks (red-flagged sections).

Click on a red section to see what causes the long task. Next, see the ‘Summary’ tab in the footer. It shows the processing time of a task. Here, in the above image, you can see that 3ms is the loading time of the function called, but the code took 662ms to process, blocking the main thread. 

For more details, you can check the ‘Bottom Up’ section as shown below. 

This image shows the processing history of the browser’s main thread during the page loading process. As you may notice, there is a Composite Code event with multiple sub-processes. On the right side, you will see the JavaScript Code that triggers the Long Task. Click on the link, and it will show you the code block, which starts this event.

Pro Tip:

Use Long Tasks API as a programmatic alternative to the method described above. It reports the instances of the long tasks and the work involved in its associate frame context.

How to minimize TBT?

The JavaScript tasks are the root cause of TBT. It blocks the browser’s main thread for extended periods and hinders the user input. 

You can use the following strategies to minimize the main thread’s blocking time caused by JavaScript.   

1. Break up long tasks 
2. Remove unused polyfills 
3. Defer unused JavaScript 
4. Async JavaScript 
5. Caching the browser  
6. Use web workers API
7. Avoid an excessive DOM size
8. Implement ‘Idle Until Urgent’
9. Optimize heavy third-party codes 
10. Lazy-loading of heavy services like Chatbots 

How does TBT correlate with FID?

First input delay (FID) is a field implementation of Core Web Vitals that depends on real user interaction. It means we cannot replicate this web performance metric in a lab setting. Furthermore, we cannot even measure it with lab tools. However, we can use Total Blocking Time (TBT) as an alternative to it. 

FID measures the time a browser takes to perform user-intended action on a web page. It’s the time between the user’s first interaction with a web page (tapping a button, hitting a link, etc.) and the browser executes the intended function. 

On the other hand, Total Blocking Time (TBT) is a user-centric web performance metric that essentially focuses on the web page’s load responsiveness. It measures the browser’s non-responsive times due to blocked main thread caused by long tasks, and therefore can closely correlate with the FID metric. 

TBT measures the total amount of time a web page takes to become interactive. It is an aggregated time between FID and TTI (Time to Interactive) when task length exceeds 50ms and blocks the main thread. 

In brief, FID and TBT affect the behavior pattern of a web page and response from the interface after the user’s first interaction. FID is how long the browser takes to respond to user input, and TBT is how long the browser’s main thread is blocked before it becomes fully responsive to user input.  

Therefore, TBT can be used as an alternative metric to FID because both represents the same thing – the web page’s responsiveness to the user interaction.

Summary

Total Time Blocking is a Non-Core Web Vitals metric that measures the total amount of time (in milliseconds) when a browser’s main thread is blocked long enough that it becomes unresponsive to the user input. It is closely related to First Input Delay, which is a Core Web Vital Metric. FID tells how long a user has to wait for a web page to show his expected output. Likewise, TBT means how long the page’s main thread is blocked before becoming fully responsive. In both cases, it is the browser delaying to respond to user input. Therefore, we can measure FID with the help of TBT. 

Improved TBT means improved FID and overall improved performance of a web page, which is necessary to rank higher in the search engines.