Total Blocking Time

Why It Matters

• It directly measures perceived responsiveness. TBT captures the moments when users are trying to interact but the page is not listening. Unlike metrics that measure painting speed, TBT tells you whether the page actually responds when someone taps a button or types in a field.
• It correlates strongly with real-world interactivity. Pages with high TBT feel sluggish even if they look fully loaded. Users experience this as buttons that do not respond, scroll jank, and input delays — all of which drive people away.
• It is a key lab metric. TBT is one of the most important performance metrics measured in controlled testing environments. It serves as a reliable proxy for how responsive the page will feel to real users.
• It exposes JavaScript-heavy loading. A page with low TBT has managed to load its JavaScript without monopolizing the main thread. High TBT means JavaScript is running in large, unbroken chunks that lock out everything else.

How to Reduce It

1. Break up long JavaScript tasks. Split large operations into smaller chunks that complete in under 50 milliseconds each. Use techniques like yielding to the main thread with setTimeout, requestIdleCallback, or the scheduler API to give the browser a chance to handle user input between chunks.
2. Reduce the amount of JavaScript. Less code means less execution time. Remove unused JavaScript, eliminate redundant libraries, and question whether every script on the page is truly necessary for the initial load.
3. Defer non-critical JavaScript. Scripts that are not needed for the initial view — analytics, below-the-fold features, third-party widgets — should load after the page becomes interactive. Move them below the fold or load them dynamically.
4. Optimize third-party scripts. Third-party code often contributes heavily to TBT. Audit the impact of each external script and remove, defer, or replace any that contribute disproportionate blocking time.
5. Use code splitting and lazy loading. Rather than sending all JavaScript in one bundle, split it by route or feature and load each piece only when needed. This dramatically reduces the amount of JavaScript that must execute during the initial page load.

Common Mistakes

• Testing only on fast hardware. TBT is heavily influenced by CPU speed. A page that scores well on a high-end laptop may have a terrible TBT on a mid-range phone. Always test on representative devices or with CPU throttling enabled.
• Focusing only on total JavaScript size. File size matters for download time, but TBT is about execution time. A small, poorly optimized script can block the thread longer than a larger but well-structured one. Both size and execution efficiency matter.
• Ignoring the 50ms threshold. Tasks that complete in under 50 milliseconds do not contribute to TBT at all. The goal is not to eliminate all JavaScript tasks — it is to keep each one short enough that the browser can respond to input between them.
• Deferring everything to after page load. Moving all JavaScript to after the load event can actually hurt the user experience by delaying interactivity for features that users expect immediately. Defer strategically, not blindly.