Have you ever clicked a button on a website and nothing happened? Or tried to scroll and the page froze for a moment? That frustrating delay is what Total Blocking Time (TBT) measures.
Total Blocking Time measures the total amount of time when a webpage is loaded but can't respond to user interactions (like clicks, taps, or keyboard presses) because the browser's main thread is busy processing other tasks. In simpler terms, it's the total time your website is "frozen" and unresponsive to visitors.
TBT is about the responsiveness of your website—how quickly it reacts when users try to interact with it. Here's why it's crucial:
Think of TBT as measuring the "frustration factor" of your website. It's not just about how fast your site loads visually—it's about how quickly visitors can actually use it.
To understand Total Blocking Time, you need to know a bit about how browsers work:
Research shows that humans perceive interactions as "instant" when they take less than 50ms. Anything longer starts to feel delayed. That's why 50ms is used as the threshold for defining a "long task."
The best way to measure Total Blocking Time is with performance monitoring tools. While your website is loading, these tools track how long the main thread is blocked and unable to respond to user input.
For accurate TBT measurements, it's important to test under realistic conditions including:
Remember that TBT can vary significantly between desktop and mobile devices. Mobile devices typically have less processing power, so they often experience longer blocking times with the same code.
The number one cause of high TBT is too much JavaScript loading and executing during page load.
Simple fix: Look for unused JavaScript that can be removed, especially in third-party tools and analytics. Use "code splitting" to load only essential JavaScript first and delay the rest.
Not all JavaScript needs to load immediately when your page loads. Much of it can be loaded later.
Simple fix: Add the "defer" attribute to script tags that aren't needed for initial page rendering. For WordPress sites, plugins like WP Rocket can help defer JavaScript automatically.
Third-party tools like analytics, marketing trackers, and social media widgets often add considerable JavaScript that blocks the main thread.
Simple fix: Audit your website for all third-party scripts and remove any that aren't providing clear value. For those you keep, consider loading them after your page becomes interactive.
Sometimes you need complex JavaScript to run, but you can break it into smaller pieces that allow the main thread to handle user interactions in between.
Simple fix: If you have custom JavaScript, work with your developer to split long processes into smaller chunks using techniques like setTimeout() or requestAnimationFrame().
Web Workers allow JavaScript to run in a background thread, keeping the main thread free to respond to user interactions.
Simple fix: For complex calculations, data processing, or other CPU-intensive tasks, move them to Web Workers so they don't block the main thread.
While images themselves don't block the main thread, the layout calculations they trigger when loading can cause blocking.
Simple fix: Always specify image dimensions in your HTML or CSS so the browser doesn't have to recalculate layout when images load. Use properly sized images for different devices.
Complex CSS selectors and animations can cause significant main thread blocking while the browser calculates styles and layouts.
Simple fix: Use simpler CSS selectors where possible and be cautious with CSS animations. Consider using the "will-change" property to prepare the browser for elements that will animate.
A "performance budget" sets limits on the amount of code your site can load, helping prevent TBT from creeping up over time.
Simple fix: Set a maximum size for your JavaScript (e.g., "no more than 300KB of JavaScript on any page") and stick to it when adding new features.
What's happening: Modern JavaScript frameworks can add significant processing time during initial page load.
Simple solution: Consider server-side rendering or static site generation to reduce client-side processing. If using React, consider using React.lazy() for component-level code splitting.
What's happening: Many websites load multiple analytics, marketing, and tracking scripts that compete for main thread time.
Simple solution: Consider consolidating analytics providers or using a tag manager that loads these scripts more efficiently. Delay loading analytics until after the page is interactive.
What's happening: Fancy animations, parallax effects, and scroll-triggered animations often cause significant main thread blocking.
Simple solution: Use CSS animations where possible (they can often run off the main thread), use the will-change property, and consider simpler effects that achieve similar visual appeal with less processing.
What's happening: When web fonts load, they can trigger layout recalculations that block the main thread.
Simple solution: Use font-display: swap to prevent font loading from blocking rendering, preload critical fonts, and consider using system fonts for better performance.
Total Blocking Time is part of a set of metrics that work together to measure different aspects of website performance:
| Metric | What It Measures | How It Relates to TBT |
|---|---|---|
| First Input Delay (FID) | How long it takes for the page to respond to the first user interaction | FID measures a single interaction delay, while TBT measures the total time the page is unresponsive |
| Time to Interactive (TTI) | When the page becomes fully interactive | TBT measures the blocking time between First Contentful Paint and Time to Interactive |
| Largest Contentful Paint (LCP) | When the main content finishes loading | A page might look loaded (good LCP) but still have high TBT making it unusable |
| Cumulative Layout Shift (CLS) | How much elements move around as the page loads | Both CLS and TBT contribute to a frustrating user experience in different ways |
The key relationship to understand is that a page might visually load quickly (good LCP) but remain unresponsive (poor TBT). Both aspects need to be optimized for a truly fast-feeling website.
Companies that have focused on reducing their Total Blocking Time have seen significant improvements in user experience and business metrics:
These examples demonstrate that responsiveness isn't just a technical concern—it directly affects how people use your website and whether they achieve their goals (and yours).
Total Blocking Time is about more than just technical performance—it's about keeping the promises your website makes to visitors. When someone clicks a button, they expect an immediate response. Each millisecond of delay breaks that trust a little bit.
By focusing on reducing your TBT, you're not just improving a technical metric; you're creating a more reliable, trustworthy experience that makes visitors feel in control. An unresponsive website, no matter how beautiful, ultimately creates frustration and lost opportunities.
The good news is that the same optimizations that improve TBT often improve other aspects of your website performance as well. By reducing JavaScript, deferring non-critical resources, and simplifying what happens during page load, you create a website that not only loads quickly but feels smooth and responsive throughout the entire user journey.
Greadme's easy-to-use tools can help you identify exactly what's causing your Total Blocking Time issues and provide simple, step-by-step instructions to fix them—even if you're not technically minded.
Improve Your Website Responsiveness Today