Lighthouse: Total Blocking Time
Total Blocking Time (TBT) is a Lighthouse Performance metric introduced in 2020 that quantifies your page's load responsiveness to user input.
In the simplest terms, TBT measures the total amount of time your webpage was blocked, preventing the user from interacting with your page.
It is one of the Web Vitals and is a replacement for the field-only First Input Delay (FID) metric, seen in PageSpeed Insights.
How does your site score on this metric?
What does Total Blocking Time measure?
According to Google, "TBT measures the total time between First Contentful Paint (FCP) and Time to Interactive where the main-thread was blocked for long enough to prevent input responsiveness."
When any one of these tasks runs longer than 50 ms (also known as a Long Task), the main-thread is considered "blocked" because the browser cannot interrupt a task in progress.
If the main-thread is blocked, your page can't respond to user inputs like screen taps, keyboard presses, or mouse clicks.
The excess time beyond 50 ms is considered the individual blocking time for that request.
The sum of all these blocking times is your page's Total Blocking Time.
For example, in the above image, there are 5 tasks on the main-thread, 3 of which are Long Tasks, as their individual durations exceed 50 ms. The blocking times for each Long Task are, as follows:
- Task A - 220 ms
- Task B - 70 ms
- Task E - 145 ms
The TBT, in this scenario, is 435ms. If, however, the main-thread only had one task that took 500 ms, the TBT would be 500 ms.
Total Blocking Time vs Time to Interactive
Time to Interactive (TTI) is another metric that is related to your page interactivity. TBT and TTI complement each other yet provide completely different perspectives on your page experience.
TTI considers a page fully interactive if the main-thread has been free of long tasks for at least 5 seconds.
Consider the following scenarios:
- A) Three 60 ms tasks spread out over a 5 second period.
- B) One 5-second Long Task.
Both of the above scenarios would push back TTI by the same amount.
However, both scenarios would feel very different to a user as the first scenario has a TBT of only 30 ms whereas the second scenario has a TBT of 4950 ms.
Scenario A is largely interactive throughout the page load, as no long tasks take up too much of the browser's time, while Scenario B is not interactable at all while the browser is busy handling the long task.
This makes TBT, both, an insightful stand-alone metric, and a useful companion metric to TTI.
Total Blocking Time vs First Input Delay
As noted earlier, TBT is a replacement for First Input Delay (FID), which is one of the Web Vitals. FID is a field-only metric that requires real user data to measure.
This real user data come in the form of Chrome User Experience Reports (CrUX) - Google's database of Chrome Browser behaviour collected from real-world Chrome users, something GTmetrix doesn't use in its testing.
Therefore, GTmetrix tests report TBT in place of FID as it serves as a suitable proxy and recommends the same optimizations. You can read more here.
Total Blocking Time's effect on your Performance Score
As a Web Vital metric, TBT accounts for 25% of the Performance Score, making it a top metric to optimize.
This highlights our increased focus on user experience to complement page speed analysis.
What this means for you is, optimizing your TBT can often make one of the most impactful improvements in your website's responsiveness.
Thresholds for Total Blocking Time
TBT thresholds are, as follows:
- Good - nothing to do here = TBT of 150 milliseconds or less.
- OK, but consider improvement = TBT between 150 and 224 milliseconds.
- Longer than recommended = TBT between 224 and 350 milliseconds.
- Much longer than recommended = TBT higher than 350 milliseconds.
How to improve Total Blocking Time?
Note that the particular audits mentioned below likely contribute the most to your TBT; however, your page's Total Blocking Time may also be affected by other optimizations that aren't mentioned here.
Some of these optimizations include:
- 2) Minimizing main-thread work
- 4) Reducing the impact of third-party code
Note: Some of the Structure audits are related; improving one is likely to improve the others.