Total Blocking Time (TBT) Metric
Total Blocking Time (TBT) is a web performance metric that reveals the total time during which a rendered page is unable to respond to user inputs.
The Total Blocking Time metric, also known as "Total JavaScript Blocking Time," measures the duration after the First Contentful Paint (FCP) when the browser's main thread is blocked by JavaScript, leaving the page unresponsive to user inputs. This is often due to sluggish JavaScript, and TBT typically has a direct impact on the crucial INP metric.
What Does Browser Blocking Mean and What Are Long Tasks?
A blocked browser main thread occurs when it must process a long task. A "long task" is any task that runs on the browser's main thread for more than 50 milliseconds.
What a click delayed by a long task looks like.
As illustrated:
- The first interaction ("Click 1") is swift because the browser can respond immediately.
- The response to the second interaction ("Click 2") is delayed because the user clicked while JavaScript was busy in the background ("Long Task").
When we say the main thread is "blocked," it means the browser cannot interrupt the ongoing task. Users click or attempt other interactions with the page but receive no response because the browser is executing a long task.
If a user interacts with a page during a long task, the browser must wait for the task to complete before it can respond.
Tasks lasting over 50 milliseconds are likely to be noticed by users, who may perceive the page as slow or unresponsive.
The total blocking time of a page, the TBT value, is the sum of the blocking times of each long task that occurs after the FCP event during the measurement period. Measurement typically concludes with the Time To Interactive (TTI) metric or when the monitoring tool stops observing.
Why Monitoring TBT Matters
Users dislike waiting, and if they must, they want to know something is happening. Once a web page displays meaningful content (FCP event occurs), users are likely to start interacting with it. If the page doesn't respond to user interactions, it may discourage users, leading them to leave.
As mentioned, TBT also affects one of the three Core Web Vitals, specifically the INP metric. If TBT is high and individual long tasks exceed 200 ms, the INP metric is likely to be worse.
Strive to generate the shortest possible long tasks on your website and minimize Total Blocking Time.
Ideal Total Blocking Time Values
For pages to deliver a good user experience, they should aim for a total blocking time (TBT) of less than 200 milliseconds when tested on "average mobile hardware." This value is recommended by the Chrome team on Web.Dev.
Let's also consider the TBT values recommended by tools like Lighthouse or derived tools like our speed monitoring.
| TBT Time | Lighthouse Rating |
|---|---|
| 0 – 200 ms | Green (fast) |
| 200 - 600 ms | Orange (moderate) |
| over 600 ms | Red (slow) |
Measuring TBT
Total Blocking Time can only be measured using synthetic measurements by a machine. There are several ways to obtain the TBT metric value for a specific page.
PageSpeed Insights
Using PageSpeed Insights, you can determine the TBT value for each URL individually.
TBT metric in the Lighthouse report, in this case within PageSpeed Insights.
Monitoring PageSpeed.ONE
In our monitoring PLUS, we not only show the current TBT value for individual URLs but also use graphs to illustrate how the metric has evolved over time.
In the Pages Report, we track TBT development for individual URLs:
Total Blocking Time for different page types on the website and its development.
Using Watchdog, we display ongoing daily development of synthetic TBT values and other metrics, sending notifications when set limits are exceeded:
TBT metric development in PageSpeed.ONE monitoring's Watchdog.
Optimizing the Total Blocking Time Metric
Optimizing the TBT metric primarily involves reducing the amount of JavaScript executed on the page.
General recommendations include:
- Limit the amount of JavaScript embedded in the page.
- Avoid unnecessary JavaScript libraries.
- Minimize the use of third-party JavaScript code.
- Minimize work on the browser's main thread.
Specific TBT issues might look like this:
- Generating a long task that handles page hydration in JavaScript frameworks like (React or Nuxt/Vue.js).
- Initializing a large number of functions that all run simultaneously upon the DOM ready event.
- Initializing various third-party JavaScript libraries used for marketing purposes, such as TikTok, Databreakers, GTM, FbEvents, etc.
- Initializing JavaScript libraries for components not visible in the initial viewport, allowing their start to be deferred.
In all cases, it's essential to limit the amount of code executed on a given page or view, or to optimize the JS code that creates long tasks. For measuring long tasks among real users, you can use the JS Long Tasks (JSLT) metric.
Manual Optimization of Long Tasks in JavaScript
Advanced users can identify specific long tasks in Chrome DevTools under the Performance tab (see measuring speed directly in the browser) and optimize particular code sections.
Finding long tasks on the web is straightforward with the following image and guide:
How to find long tasks in Chrome DevTools.
- Launch Chrome with DevTools (F12) or and display the page you want to optimize.
- Open the Performance tab (see image #1).
- Use the Reload and Record function to capture the page loading process (see #2).
- Record the page loading timeline.
- In the Main line (work on the main thread), you'll see red-striped long tasks lasting over 50 ms (see #3).
- By clicking inside the long task, you can determine which part of the JavaScript is problematic (see #4).
For more on optimizing long tasks, see our article on INP metric optimization.