Total Blocking Time

What is TBT

Total Blocking Time (TBT) is the total amount of time that the main thread of a webpage gets blocked due to long tasks, preventing it from responding to user interactions while processing the load. Apart from the core web vitals, it is a crucial lab metric that measures the responsiveness or usability of a web page before it becomes fully interactive.

What TBT Measures

TBT is the total time between the First Contentful Paint (FCP) and Time to Interactive (TTI). The main thread of the browser usually executes several tasks during a web page load, and TBT specifically depends on the number of long tasks running during that time.

Main Thread

The main thread of the browser performs several tasks during web page rendering, including important tasks like parsing HTML, DOM construction, executing JavaScript and CSS, garbage collection, event processing, etc.

Long Task

A long task is one that takes more than 50 ms to run on the main thread. The main thread gets blocked during its execution as the browser cannot interrupt a running task. Thus, the main thread cannot respond to any user interaction during that blocking period.

The Total Blocking Time is the sum of all the blocking times of such long tasks. For example, the following diagram shows some tasks running on the main thread during a page load.

Example tasks running on the main thread during a page load

In the above diagram, all the tasks except the 40 ms one are long tasks. The following diagram shows the amount of time the main thread gets blocked due to long tasks.

The task blocking times during a page load
Tasks Task Duration (ms) Main thread blocking time (ms)
1 250 200
2 150 100
3 40 0
4 100 70
5 70 50
Total 610 420

Here the Total Blocking Time is 420 ms.


How TBT Affects User Experience

Users may interact with a web page even when it has loaded only some of its content and before it becomes fully interactive. For example, users may interact with the browser during the initial page load using mouse clicks, keyboard presses, screen taps, etc. Long-running tasks prevent the main thread from responding to such input, which frustrates users. In addition, having a large TBT makes TTI larger, meaning that users have to wait a long time until the page becomes fully interactive, leading to further frustration. Such scenarios affect the overall user experience of the website, leading to poor user conversion and a higher bounce rate.

How TBT Affects SEO

Search engine algorithms consider the user experience when ranking web pages. If a web page has many blocking tasks, it can affect search queries by users that need a quick response, so having many blocking tasks can directly impact the SEO rankings of a page.

How TBT Relates to Other Core Web Vitals

While TBT, TTI, and First Input Delay (FID) are similarly related to the interactivity of a web page, they are quite different from each other.

How TBT Differs from TTI

TTI is the time it takes for a web page to become completely ready for user interactions. When the page reaches TTI, it shows useful content or reaches FCP, and event handlers are registered for the most visible elements. The web page responds to user interactions within 50 ms.

In contrast, TBT measures how long a web page remains non-responsive to user events before it reaches TTI. So, if a user interacts with a web page between FCP and TTI, the user will experience a delay in the response as the main thread is busy at that time.


How TBT Relates to FID

FID is the time a webpage takes to respond to a user’s very first interaction with it. If there is a long time between FCP and TTI, and a user initiates the first interaction between those times, there will be a huge delay in the response. If FID happens at the start of a long-running task, the event will have to wait until the end of the execution of that task. Therefore, a busy main thread is a culprit behind a larger FID, meaning TBT directly affects the FID score.

The Business Impact of TBT: A Case Study

Mercado Libre is one of the largest e-commerce companies in Latin America; it has a presence in 18 countries and is the market leader in Brazil, Mexico, and Argentina. A case study done by Google claims that it could optimize FID and its  TBT, where they have received a 90% reduction in Max Potential FID in Lighthouse. 

Mercado Libre formed a team to identify improvement areas in its website that would result in improved user experience, longer shopping sessions, lower bounce rate, and therefore higher sales. Slow web application performance is the main culprit behind a suboptimal user experience. The company discovered that its product detail pages have poor FID using the Chrome User Experience Report, so it focused on improving web page interactivity. During those efforts, team members identified several tasks that block the main thread (the following figure) using WebPageTests. Additionally, it identified that Max Potential FID was 1710 ms using Lighthouse. 

Tasks that block the main thread during the loading of product details pages of Mercado Libre

The company took several steps to mitigate these issues. First, it reduced the main JavaScript bundle size, optimizing compile and parse times. In addition, it used code-splitting and a partial hydration technique to use the main thread in an optimized manner. Through these optimizations, the firm was able to reduce the Max Potential FID from 1710 ms to 200 ms. The efforts continued to optimize TBT using code-splitting, third-party script optimization, and improved asset bundling. 

How to Measure TBT

What Is a Good TBT Score? 

Generally, a good TBT score is under 300 ms. The following table shows how the TBT value matches the performance of a webpage according to Google Lighthouse.

TBT (milliseconds) Interpretation with Colour Code
0-200 Fast (Green)
200-600 Moderate (Orange)
Over 600 Slow (Red)

Measuring TBT

You can calculate TBT using the following tools:

In the following example, we’ll measure TBT using WebPageTest. You can go through the following steps to run a test on your chosen web page and retrieve the core web vitals:

  1. Go to https://webpagetest.org/.
  2. Select the web vitals tab from the main page.
  3. Enter the web page URL you want to test; we used this URL.
  4. Select the test configuration you want. 
  5. Start the test and wait a couple of minutes to get the final results.
  6. Go to the performance test results page and click on the Web Vitals section. There you can see the Total Blocking Time listed along with the other core web vitals.

So, in our example, the TBT is 3720 ms, which is a large value. The Largest Contentful Paint (LCP) is 2204 ms, and the Cumulative Layout Shift (CLS) is 0.178. These web vitals indicate that this page is considerably slow. You can find the test results of the above test conducted on WebPageTest here.

Web vital for the page load : https://www.imdb.com/?ref_=nv_home

WebPageTest also visualizes the long tasks and provides their main thread blocking times by script origin

Visualization of the long tasks and main thread blocking times by script origin


Factors Contributing to Poor TBT

1. Large Third-Party Scripts

Third-party JavaScript in web pages can be important for various purposes, like capturing analytics, social sharing, embedding video players, etc. Such scripts may contain unoptimized content that significantly reduces performance and also makes additional network requests. Additionally, rendering will get blocked if the third-party server has any problem that causes it to fail to deliver the requested resources. In all these ways, third-party scripts can contribute to long-running tasks.

Web vitals for the page https://www.bbc.com/news/world

You can identify slow-running third-party scripts using WebPageTest. For example, the following images are screenshots of the web vitals for the page https://www.bbc.com/news/world, which you can find in this link. There, you can see that the TBT is 7334 ms, which is a very poor score.

Waterfall view of the page load for https://www.bbc.com/news/world

The test shows that the page contains several third-party scripts that block the main thread for more than 300 ms.

Main thread blocking time by the script origin

How to Fix the Problem

The solution here is to limit the number of redundant third-party scripts and load them once the basic loading of the web page is completed.


2. High JavaScript Execution Time

Network, memory, compilation, and execution costs are associated with JavaScript execution time. Issues like less optimized code, unused scripts, and coding errors result in long-running JavaScript. Parsing, compiling, and executing inefficient script files takes a significant amount of time, affecting the overall page load time. 

WebPageTest can indicate the execution times (CPU times) of scripts. For example, the following image is extracted from the table that lists all the web page requests in the previous example (https://www.bbc.com/news/world). 

Execution times of web page resources

From the above table, you can see that some JavaScript scripts have execution times over 1000 ms, which will cause slowdowns.

How to Fix the Problem

  • Code Splitting

Code splitting can greatly reduce the impact of long-running JavaScript on page load speed. Instead of including all the JavaScript scripts at once when loading the first page, split them into multiple bundles and load only the essential files as needed. 

  • Reduce the Use of Third-Party JavaScript

A web page can have dependencies on too many external JavaScript libraries. Reduce their use wherever possible and load them only when they are necessary for the page.

  • Minifying the Code

JavaScript and CSS files can contain unnecessary characters like newlines and spaces, contributing to slower page loads. Code minifying eliminates such useless code and compresses it.

3. Main Thread with Too Much Work to Do

The main thread is the critical part of a web page that handles most of the work. By default, it handles most of the core processes, such as parsing, evaluating, and executing the JavaScript and CSS, building the DOM, applying the specified styles, processing user events, etc. If the main thread is busy with these tasks, it can take a long time for the page to become interactive.

For example, the WebpageTest results for the page https://www.bbc.com/news/world provide a detailed view of all the activity times of the main thread, including the idle time.

 Activity times of the main thread

The PageSpeed Insights tool also shows how the main thread spends its time performing various tasks. According to the results, the main thread has spent a large amount of time on script evaluation. 

PageSpeed Insights tool showing the main thread work breakdown

When you know where the main thread takes more time, you can identify where to optimize. 

How to Fix the Problem

Optimize the main thread work by: 

  • Using web workers
  • Reducing script evaluation time
  • Reducing style and layout recalculation
  • Minifying CSS
  • Removing unused code
  • Deferring unused and noncritical JavaScript
  • Avoid using long-running input handlers


4. Excessive DOM Size

TBT also increases when the web page consists of a large DOM tree, which means that the web page includes many invisible DOM nodes during the initial page load, increasing memory usage. Not only that, when the DOM tree has sophisticated styling, the browser needs to recalculate the styling and the position of nodes every time a user interacts with it. Excessive DOM size causes the main thread to get blocked by longer tasks. 

The PageSpeed Insights tool can also indicate if the page has excessive DOM size. The following images show the results of our example https://www.bbc.com/news/world. According to the results, the web page has 3,750 DOM elements.

PageSpeed Insights tool showing the DOM size of the page

How to Fix the Problem

  • Choose different libraries in JavaScript that eliminate the need to load repeated nodes on the page. For example, you can use the react-window for a web page that uses react.
  • Use lazy loading.
  • Split the webpage into multiple pages.

 5. High Network Request Count and Transfer Sizes

A larger number of network requests also causes a higher TBT value. For example, the following image shows the breakdown of request counts by domain for our example  https://www.bbc.com/news/world. According to the results, more requests have come from third-party domains apart from their own domain. Additionally, you can use the PageSpeed Insights tool to get an idea of how many requests arrive for each type as images, scripts, style sheets, and third-party domains, and the sizes of their payloads. 

Network requests per domain 

How to Fix the Problem

  • Optimize JavaScript and CSS files by code minification, removing unused scripts, code splitting, serving modern code, etc.
  • Optimize your images using techniques like image compression, choosing the correct image format, using image CDNs, using video instead of animated GIFs, serving responsive images, lazy loading, etc. 
  • Use reduced font sizes and eliminate invisible text.
  • Optimize third-party scripts by choosing third-party code.


TBT is an important lab metric that estimates the responsiveness and usability of a web page before it becomes interactive. As we learned from this article, it directly affects the user experience and SEO of a website. There are several reasons for poor TBT, which you can discover using WebPageTest. The main reason behind poor TBT is unoptimized third-party JavaScript code; website owners can improve TBT by following the optimization options described in this article, as many businesses already do.