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