Total Blocking Time

What is TBT

Total Blocking Time (TBT) measures the moments during page load when the browser’s main thread is tied up with long tasks and cannot react to clicks, taps, or keypresses. It is a key lab metric for gauging how responsive and usable a page feels before it reaches full interactivity.

What TBT Measures

TBT measures the portion of time between First Contentful Paint (FCP) and Time to Interactive (TTI). when your page is effectively “too busy” to respond to users. As the browser’s main thread processes everything needed to load the page, long-running tasks pile up, and TBT captures the total blocking time created by those tasks.

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 any operation on the main thread that takes more than 50 ms to complete. While that task is running, the browser cannot pause or interrupt it, so the main thread is effectively blocked and cannot respond to clicks, taps, or keypresses during that time.

Total Blocking Time is the sum of all those blocking periods from long tasks during page load. In the diagram below, every task except the 40 ms one counts as a long task, and their combined blocking time adds up to the page’s TBT.

The diagram below shows how long the main thread is blocked by long tasks.

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 initial page load using mouse clicks, keyboard presses, and screen taps. Long-running tasks prevent the main thread from responding to such input, which frustrates users. In addition, having a large TBT makes TTI longer, meaning users have to wait a long time for the page to become 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 who 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

Time to Interactive (TTI) is how long it takes for a page to become fully ready for user interaction, with meaningful content on screen and event handlers wired up for key elements. At TTI, the page can reliably respond to user input within about 50 ms, so it feels responsive rather than sluggish.

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, they will experience a delay in response because the main thread is busy.

How TBT Relates to FID

First Input Delay (FID) measures how long it takes a page to respond to a user’s very first interaction, such as a click or tap. When there is a long window between FCP and TTI and the user interacts during that time, any long-running task on the main thread will delay that first response until it finishes. A busy main thread, therefore, tends to produce higher FID, which is why high TBT usually goes hand in hand with poor FID scores.

The Business Impact of TBT: A Case Study 

Mercado Libre is one of the largest e-commerce companies in Latin America, with a presence in 18 countries, and market leadership in Brazil, Mexico, and Argentina. In a published case study, the company achieved a 90% reduction in Max Potential FID in Lighthouse by optimizing both FID and TBT. To get there, Mercado Libre formed a team to identify areas for improvement on its website that would result in a better user experience, longer shopping sessions, a 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 using WebPageTests (see the following figure). 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 reduced the Max Potential FID from 1710 ms to 200 ms. The efforts continued to optimize TBT through 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 table below shows how the TBT value aligns with a webpage’s performance as measured by Google Lighthouse.

Measuring TBT

You can calculate TBT using the following tools:

• WebPageTest
• Google PageSpeed Insights
• Chrome Dev Tools

Factors Contributing to Poor TBT

1. Large Third-Party Scripts

Third-party JavaScript on web pages can serve various purposes, such as collecting analytics, enabling social sharing, and embedding video players. Such scripts may contain unoptimized content that significantly reduces performance and also makes additional network requests. Additionally, rendering will be blocked if the third-party server experiences a problem that prevents it from delivering the requested resources. In all these ways, third-party scripts can contribute to long-running tasks.

You can identify slow-running third-party scripts using WebPageTest. For example, the screenshot below shows the web vitals for the page https://www.bbc.com/news/world. The TBT of 7334 ms is a very poor score.

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

The solution here is to limit the number of redundant third-party scripts and load them only after the basic page load is complete.

2. High JavaScript Execution Time

Network, memory, compilation, and execution costs affect JavaScript execution time. Issues such as poorly 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 listing all web page requests in the previous example (https://www.bbc.com/news/world).

In the table above, you can see that some JavaScript scripts take over 1000 ms to execute, which can 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 necessary for the page.
• Minifying the Code: JavaScript and CSS files can contain unnecessary characters, such as newlines and spaces, which can slow page loads. Code minification eliminates unnecessary 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 core processes, such as parsing, evaluating, and executing JavaScript and CSS, building the DOM, applying the specified styles, processing user events, etc. If the main thread is busy with these tasks, the page may take a long time 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.

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.

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 DOM tree is large, meaning the page includes many invisible nodes during initial page load, which increases memory usage. Not only that, when the DOM tree has complex styling, the browser needs to recalculate the styling and node positions every time a user interacts with it. Excessive DOM size can cause the main thread to be blocked by long-running 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.

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 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.

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. 

Wrap-Up

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.

FAQs