Total Blocking Time (TBT)

Total Blocking Time (TBT)

Available in: Español, 日本語, 한국어, Português, Русский, 中文, English
Appears in: Metrics

Total Blocking Time (TBT) is an important lab metric for measuring load responsiveness because it helps quantify the severity of how non-interactive a page is prior to it becoming reliably interactive—a low TBT helps ensure that the page is usable.

What is TBT? #

The Total Blocking Time (TBT) metric measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent input responsiveness.

The main thread is considered "blocked" any time there's a Long Task—a task that runs on the main thread for more than 50 milliseconds (ms). We say the main thread is "blocked" because the browser cannot interrupt a task that's in progress. So in the event that a user does interact with the page in the middle of a long task, the browser must wait for the task to finish before it can respond.

If the task is long enough (e.g. anything above 50 ms), it's likely that the user will notice the delay and perceive the page as sluggish or janky.

The blocking time of a given long task is its duration in excess of 50 ms. And the total blocking time for a page is the sum of the blocking time for each long task that occurs between FCP and TTI.

For example, consider the following diagram of the browser's main thread during page load:

A tasks timeline on the main thread

The above timeline has five tasks, three of which are Long Tasks because their duration exceeds 50 ms. The next diagram shows the blocking time for each of the long tasks:

A tasks timeline on the main thread showing blocking time

So while the total time spent running tasks on the main thread is 560 ms, only 345 ms of that time is considered blocking time.

Task durationTask blocking time
Task one250 ms200 ms
Task two90 ms40 ms
Task three35 ms0 ms
Task four30 ms0 ms
Task five155 ms105 ms
Total Blocking Time345 ms

How does TBT relate to TTI? #

TBT is a great companion metric for TTI because it helps quantify the severity of how non-interactive a page is prior it to becoming reliably interactive.

TTI considers a page "reliably interactive" if the main thread has been free of long tasks for at least five seconds. This means that three, 51 ms tasks spread out over 10 seconds can push back TTI just as far as a single 10-second long task—but those two scenarios would feel very different to a user trying to interact with the page.

In the first case, three, 51 ms tasks would have a TBT of 3 ms. Whereas a single, 10-second long tasks would have a TBT of 9950 ms. The larger TBT value in the second case quantifies the worse experience.

How to measure TBT #

TBT is a metric that should be measured in the lab. The best way to measure TBT is to run a Lighthouse performance audit on your site. See the Lighthouse documentation on TBT for usage details.

Lab tools #

While it is possible to measure TBT in the field, it's not recommended as user interaction can affect your page's TBT in ways that lead to lots of variance in your reports. To understand a page's interactivity in the field, you should measure First Input Delay (FID).

What is a good TBT score? #

To provide a good user experience, sites should strive to have a Total Blocking Time of less than 200 milliseconds when tested on average mobile hardware.

For details on how your page's TBT affects your Lighthouse performance score, see How Lighthouse determines your TBT score

How to improve TBT #

To learn how to improve TBT for a specific site, you can run a Lighthouse performance audit and pay attention to any specific opportunities the audit suggests.

To learn how to improve TBT in general (for any site), refer to the following performance guides:

Last updated: Improve article