TL;DR: Total Blocking Time (TBT) is a web performance metric that measures the time during page loading when the main thread is blocked and users experience delays interacting with the page. To enhance TBT, focus on optimizing JavaScript, minimizing render-blocking resources, and utilizing performance tools like Lighthouse. Efficiently managing third-party scripts, prioritizing critical resources, and employing asynchronous loading techniques contribute to reducing TBT, resulting in a smoother and more responsive user experience on your site.
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:
- What TBT 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 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?
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.
To calculate TBT, we need 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.
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.
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.
Final Thoughts
TBT is definitely a metric that you need to keep an eye on when optimizing your site's performance.
While Total Blocking Time isn’t a part of Google’s Core Web Vitals program, Largest Contentful Paint and Cumulative Layout Shift are.
They both affect your website's organic ranking, so learn what you can do about these page experience metrics and get to work.
