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. It’s also the most heavily weighted metric in your Lighthouse performance score—around 30%—and the lab proxy for Interaction to Next Paint (INP), Google’s field metric for responsiveness. To enhance TBT, focus on optimizing JavaScript, minimizing render-blocking resources, and managing third-party scripts.
Total Blocking Time (TBT) accounts for roughly 30% of your Lighthouse performance score—more than any other single metric.
This is a result of an update to the technology that powers PSI—Lighthouse. Version 6 reshaped the old metrics, removing First CPU Idle (FCI) and First Meaningful Paint (FMP) and adding TBT, LCP, and CLS to the mix—which is why TBT now carries so much weight.
In this article, you learn what TBT is, how Google measures it, what counts as a good score, and how to check which tasks hurt it.
Test NitroPack yourself
By submitting, you agree to our Privacy Policy.
What is Total Blocking Time (TBT)?
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 one 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 we noted 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 they love that.
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, how does that look?
| Task | Duration | Blocking time (over 50ms) |
|---|---|---|
| Task 1 | 260 ms | 210 ms |
| Task 2 | 30 ms | 0 ms (under the 50ms threshold) |
| Task 3 | 100 ms | 50 ms |
| Task 4 | 60 ms | 10 ms |
| Total TBT | 270 ms |
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.
⚠️ Important for 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.
What’s a good TBT score?
A good TBT is 200 milliseconds or less. Google measures the thresholds against a mobile device, since most people browse on slower mobile CPUs, and applies a tighter target on desktop.
| Device | Good | Needs improvement | Poor |
|---|---|---|---|
| Mobile | 0–200 ms | 200–600 ms | Over 600 ms |
| Desktop | Under 150 ms | — | — |
Because mobile is the stricter test, treat the mobile thresholds as your primary target.
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 (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 by giving you a detailed picture of how severely the interactivity was affected by long tasks, rather than pointing out when a page became interactive. This makes it a great standalone metric and a fantastic companion to TTI.
TBT vs INP: what’s the connection?
TBT is a lab metric. It’s measured in a controlled test, not from real users. Its field equivalent is Interaction to Next Paint (INP), which records how quickly your page responds to real interactions. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Both track main-thread responsiveness, so lowering your TBT in the lab usually improves your INP in the field.
How to improve your TBT
You don’t need a deep DevTools session to know what drags TBT down—it almost always comes back to JavaScript tying up the main thread. A few moves do most of the work:
- Defer or remove unused JavaScript, so it isn’t competing for the main thread.
- Break up long tasks into smaller chunks the browser can pause between.
- Move heavy work to web workers, off the main thread entirely.
- Reduce the impact of third-party scripts, a common hidden cause.
If hand-tuning all of that sounds like a lot, it is. This is where an all-in-one performance suite earns its keep: NitroPack handles it automatically through features like Delayed JavaScript Execution, which holds non-critical scripts until a user interacts, and Optimize Interactive Elements, which keeps the page responsive while it loads.
Final thoughts on TBT
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, the current metrics—Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint —all shape how Google judges your page. TBT is the lab proxy that predicts INP, so the work you put into lowering it pays off in the metrics that influence your rankings.
FAQs
Is total blocking time a Core Web Vital?
No. INP is the Core Web Vital for responsiveness. TBT is its lab-based proxy, measured in synthetic tests rather than from real users.
Is TBT a direct SEO ranking factor?
Not directly. But TBT predicts INP, which is part of Core Web Vitals and does influence rankings, so improving TBT helps indirectly.
What causes high TBT?
Long, heavy JavaScript tasks and third-party scripts that occupy the main thread and stop it responding to input.
What’s a good TBT on mobile vs desktop?
Under 200 ms on mobile and under 150 ms on desktop is considered good.
