Join our webinar and get expert insights on how to pass LCP →
Total Blocking Time (TBT) is the most important metric (along with LCP) for your score in Google's PageSpeed Insights (PSI).
This is a result of an update to the technology that powers PSI - Lighthouse.
Version 6 of Lighthouse changed up all the old metrics.
Most specifically, it removed First CPU Idle (FCI) and First Meaningful Paint (FMP) while adding TBT, LCP, and CLS to the mix.
As you can see, TBT is a big deal right now. And there are a few reasons for that.
In this article, you learn:
Let's get started.
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 the browser can’t interrupt them while they're running, 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.
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?
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.
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.
To calculate TBT, we need to do two things:
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:
Keep this in mind while looking for ways to improve your TBT.
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.
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.
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.
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.
You can also click on “Bottom-Up” to see a detailed description of each task.
From there, you can break down each activity and see what causes delays.
Another option is to analyze your website’s total blocking time is to use the Lighthouse audit in Chrome.
Again, right-click, select “Inspect”. This time go to “Lighthouse”.
Select the categories you want to test for and click “Generate 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 on how to improve total blocking time 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.
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.
TBT is definitely a metric that you need to keep an eye on when optimizing your site's performance.
They both affect your website's organic ranking, so learn what you can do about these page experience metrics and get to work.
Evgeni writes about site speed and makes sure everything we publish is awesome.