Login
Sign Up
What is Total Blocking Time (TBT)? [New Page Speed Metric]
TBT provides crucial new insights while complementing other well-established metrics
What is Total Blocking Time (TBT)? [New Page Speed Metric]

What is Total Blocking Time (TBT)? [New Page Speed Metric]

Total Blocking Time is the most important metric (along with LCP) for your score in PageSpeed Insights.

This is a result of a recent update to the technology that powers PSI - Lighthouse.

The latest version of Lighthouse (v6) affected all the old metrics. 

Most importantly, it removed First CPU Idle (FCI) and First Meaningful Paint (FMP) while adding TBT, LCP and CLS to the mix.

New PSI (Lighthouse) Metrics

Source: web.dev - “What's New in Lighthouse 6.0”

As you can see, TBT is a big deal right now. And there are a few reasons for that.

In this article, you learn:

  • What TBT Is
  • What The Main Thread Is
  • How Google Measures TBT    
  • The Differences Between TBT and TTI
  • How To Check Which Tasks Hurt Your TBT

Let's get started.

What is Total Blocking Time (TBT)?

Total Blocking Time (TBT) is the amount of time, during which Long Tasks (all tasks longer than 50ms) block the main thread and affect the usability of a page. It shows how unresponsive a page is before it becomes fully interactive.

Let’s break this definition down into its components.

First, a Long Task is a task that runs on the main thread for longer than 50ms. Long Tasks block the main thread because while they’re running the browser can’t interrupt them. Even in the case of user input.  

Next, we need to understand a few things about the main thread.

The main thread is the star of the show when it comes to visualizing (rendering) a page. The browser relies on it for a ton of things.

After the browser gets a code file, the main thread parses the HTML and turns it into a Document Object Model (DOM). The main thread then parses the CSS and determines the style for each element.

The main thread also performs about a billion other jobs.

Main Thread's Tasks

If you want a detailed description of everything that goes on behind the scenes, check out this awesome article by Mariko Kosaka.

For now, let’s stick to TBT’s role in all of this.

Okay, so the main thread does all the heavy lifting. What’s wrong with that?

Well, the main thread is overworked. And by default, all JavaScript runs on it. This would be fine if the main thread didn’t have other things to do. But it does.

And, as I said above, the browser can’t interrupt a task that’s already started. As a result, a long JS function can block the thread entirely, regardless of what the function is responsible for.

In such cases, the page becomes unresponsive. Users have to wait before their input produces a result.

And we all know how much users love waiting.

How Google Measures TBT 

Let’s look at some made-up examples to understand how Google measures this metric.

Say we’ve got four tasks running on the main thread. 

Task one takes 260ms, task two - 30ms, task three - 100ms and task four - 60ms.

Four Main Thread Tasks

To calculate TBT, we need the to do two things:

  • Calculate the blocking time of each task
  • Add all the results together 

Remember, only the time above 50ms is considered blocking time.

So, Task One is 260ms long, 210ms of which are blocking. Task Two takes less than 50ms, so it doesn’t contribute to the TBT. Task Three is 100ms long, 50ms of which are blocking. And Task Four is 60ms long, 10ms of which are blocking.

By adding 210ms, 50ms and 10ms, we get our TBT. In our case, that’s 270ms.

Let’s look at another example.

Say we’ve only got one task on the main thread that’s 400ms long. At first, one task sounds better than four. 

However, the blocking time of that task would be 350ms. Even though it’s only one task, it blocks more time than the four tasks in the example above combined.

And that's a vital point to consider when talking about TBT: 

A small number of tasks on the main thread doesn’t necessarily mean low blocking time. Conversely, a large number of tasks doesn’t necessarily lead to tons of blocking time or a bad user experience.

Keep this in mind while looking for ways to improve your TBT.

The Differences Between TBT and TTI

At first glance, TBT sounds just like Time To Interactive (TTI). But while similar, both metrics ultimately measure different things.

TTI tells you how long it takes for the page to become fully interactive, measured in seconds. To be considered interactive, the page has to display useful content and respond to user inputs in less than 50ms. Also, event handlers have to be registered for most page elements.

But when exactly does the page display useful content?

Well, First Contentful Paint’s (FCP) measures that. FCP tells you when the first text or image was painted.

This is where TBT comes in. TBT measures what’s happening between FCP and TTI.

FCP, TBT and TTI

When visitors try to interact with a page during that period, delays occur because the main thread is busy. TBT helps quantify the severity of these delays. 

That’s why TBT is awesome. It gives you a detailed picture of how severely the interactivity was affected by long tasks, rather than pointing out when a page became interactive.

That’s why TBT is a great standalone metric and a fantastic companion to TTI. 

How To Check Which Tasks Hurt Your TBT

The Chrome Dev Tools Performance and Lighthouse audits can give you information about Long Tasks on the main thread.

First, let’s check out the Performance audit. 

Go to a page you want to analyze. Right-click and select “Inspect”. After that, click on “Performance”.

Click on the “Reload” button and wait for Chrome to do its thing. 

Reload Button

You’ll get a detailed analysis of how the page performed. In the “Main” section, you’ll see tasks painted in different colors. If you see a gray task with a small red overlay, you’ve found a Long Task. When you hover over it, you’ll see how much time it takes up on the main thread.

Long Tasks On Main Thread

You can also click on “Bottom-Up” to see a detailed description of each task.

Bottom-Up Breakdown

From there, you can break down each activity and see what causes delays.

Another option is to use the Lighthouse audit in Chrome.

Again, right-click, select “Inspect”. This time go to “Lighthouse”.

Lighthouse Audit 1

Select the categories you want to test for and click “Generate report”.

Lighthouse Report

You’ll probably get a ton of suggestions for your website. And a lot of them can help with TBT in one way or another.

However, the two most common suggestions for improving TBT are to reduce the impact of third-party code and minimize the load on the main thread. 

You’ll find these tips in the “Diagnostics” section.

Diagnostics Section

This report won’t give you a granular breakdown of tasks, but it’ll point you to specific performance problems.

Both audits have all the information you need to find the source of your issues with TBT.

Final Thoughts

TBT is the third new metric that was added to PSI with the Lighthouse 6 update.

If you want to learn more about the other two metrics, check out our articles on Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS)

While TBT isn’t a part of Google’s Core Web Vitals program, LCP and CLS are. Both will become ranking factors somewhere in 2021.

If you start optimizing for TBT, LCP and CLS today, you can get a head start on the competition in terms of user experience and SEO.

So, learn what you can about these new metrics and get to work.

If you want to keep up with new metrics, performance optimization tactics and all other things related to website speed, subscribe to our newsletter below.

Stay tuned

Subscribe to our newsletter and stay updated!