Chapter 4:
Total Blocking Time
December 15, 2021
15 min read
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.
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.
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.
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.
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.
Here the Total Blocking Time is 420 ms.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
WebPageTest also visualizes the long tasks and provides their main thread blocking times by script origin
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.
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.
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 once the basic loading of the web page is completed.
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).
From the above table, you can see that some JavaScript scripts have execution times over 1000 ms, which will cause slowdowns.
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.
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.
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.
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.
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.
Optimize the main thread work by:
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.
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.
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.