Total Blocking Time (TBT) is the web performance metric that measures the total time the browser's main thread was blocked long enough to prevent user interaction. A high TBT means your page may look loaded but won't respond to clicks or taps — a deeply frustrating experience.
What Exactly Does TBT Measure?
The browser runs almost everything on a single main thread: HTML parsing, JavaScript execution, style calculations, and painting. When a task on that thread takes longer than 50 ms, it's classified as a long task.
TBT adds up the blocking portion of every long task that occurs between First Contentful Paint (FCP) and Time to Interactive (TTI). The blocking portion is everything beyond the 50 ms threshold.
For example: if a JavaScript task takes 200 ms, the first 50 ms are "normal" execution time and the remaining 150 ms are blocking time. If three such tasks occur in the FCP-to-TTI window, the TBT would be 450 ms.
Google's TBT Thresholds
Google evaluates TBT in lab tools like Lighthouse. Here are the official ranges:
| Rating | TBT |
|---|---|
| Good | < 200 ms |
| Needs Improvement | 200 – 600 ms |
| Poor | > 600 ms |
The goal is to keep TBT under 200 ms to deliver a responsive experience from the first second of interaction.
TBT and Core Web Vitals: Is It the Same as INP?
This is a common point of confusion. TBT is a lab metric — measured under controlled conditions with Lighthouse or WebPageTest — and serves as a proxy to predict Interaction to Next Paint (INP), which is a field metric (real user data) and an official Core Web Vital.
A high TBT in the lab typically correlates with a high INP in the field. Reducing TBT is, in practice, reducing the risk that real users experience delays when interacting with your site.
Explore more field metrics and performance fundamentals in our web performance article hub.
Common Causes of High TBT
Excessive JavaScript on the Main Thread
This is the number one cause. Third-party scripts (chatbots, analytics pixels, social widgets), heavy frameworks loaded in a blocking way, or poorly optimized application code can easily trigger long tasks.
JavaScript Framework Hydration
Frameworks like React, Vue, or Angular run DOM hydration when the page loads. If too much JavaScript is sent to the client, this process can block the main thread for hundreds of milliseconds.
Analytics and Marketing Scripts
Google Tag Manager with dozens of active tags, Meta pixels, live chat scripts — each one runs code on the main thread. The accumulation creates multiple long tasks that inflate TBT.
Polyfills and Non-Tree-Shaken Libraries
Including the full lodash library when you only use three functions, or polyfills for already-obsolete browsers, adds unnecessary weight that the main thread must parse and execute.
How to Reduce TBT: Step by Step
- Break up long tasks: use
setTimeout,scheduler.postTask(), orrequestIdleCallback()to split heavy work into chunks under 50 ms. - Defer non-critical JavaScript: add
deferorasyncattributes to scripts you don't need for the initial interaction. - Load third-party scripts carefully: assess the real cost of each script. Use DevTools' Coverage tab to identify unused code.
- Reduce bundle size: minification, tree-shaking, and code-splitting to load only what the current route needs.
- Move work to the server or to workers: Web Workers run code on a separate thread, leaving the main thread free.
- Lazy-load heavy components: dynamically import modules that the user only needs on click or scroll.
If you want a technical review of what's blocking your site's main thread, the team at elenlace.com can identify the culprit scripts and propose an optimization plan.
How to Measure Your Site's TBT
As a lab metric, TBT is measured with tools that simulate page load:
- Google Lighthouse (in Chrome DevTools or as an extension): shows TBT alongside all other performance metrics.
- PageSpeed Insights: runs Lighthouse on Google's servers and also displays field data when available.
- WebPageTest: lets you choose device, network speed, and location for a more detailed analysis.
Always run tests in private browsing mode with extensions disabled to avoid noise in the results. For representative scores, repeat the test three times and average the results.
Key Takeaways
- TBT measures the total time the browser's main thread is blocked between FCP and TTI.
- Under 200 ms is the target; above 600 ms is considered poor.
- It's a lab metric and serves as a predictor of INP (the field Core Web Vital for interactivity).
- The primary cause is excessive JavaScript on the main thread: third-party scripts, large bundles, and missing lazy loading.
- Key strategies: break up long tasks, defer non-critical scripts, and reduce bundle size.
Is Lighthouse showing a high TBT and you're not sure where to start? The team at elenlace.com offers performance audits that pinpoint the specific long tasks on your site and deliver a clear action plan.
FAQ
Does TBT directly affect Google rankings?
Not directly. Google uses Core Web Vitals (LCP, INP, CLS) as ranking signals, and these are field metrics. However, a high lab TBT predicts a high field INP, so reducing it does improve your chances of good Core Web Vitals scores — and therefore better search performance.
What's the difference between TBT and TTI?
TTI (Time to Interactive) is the point in time when the page is fully ready for interaction. TBT is the accumulated blocking time during the window from FCP to that TTI. Where TTI is a point in time, TBT is a cumulative duration.
Is a TBT of 0 ms possible?
Yes, if the page executes no long tasks between FCP and TTI. This happens on very simple pages with no or minimal JavaScript. For complex sites, targeting under 200 ms is the realistic goal.
Can I improve TBT without changing my JavaScript framework?
Yes. Deferring and async-loading third-party scripts, removing unused scripts, and splitting the bundle into smaller chunks via code-splitting are improvements that don't require changing frameworks — and can significantly reduce TBT.
Further reading
Other providers and guides worth comparing:
