Total Blocking Time

Total Blocking Time
Name	Total Blocking Time
Abbreviation	TBT
Introduced	2019
Primary use	Web performance metric
Related	First Contentful Paint, Time to Interactive, Largest Contentful Paint, Cumulative Layout Shift
Units	milliseconds

Total Blocking Time

Total Blocking Time is a web-performance metric introduced to quantify main-thread responsiveness between First Contentful Paint and Time to Interactive on the Chrome and Lighthouse performance stack. It complements metrics such as Largest Contentful Paint and Cumulative Layout Shift to provide an indicator of how long a page prevents user input processing during initial load. Major platforms and organizations including Google, Mozilla, Microsoft, Apple and performance tooling projects like WebPageTest and GTmetrix have adopted or discussed TBT when evaluating interactivity and perceived responsiveness.

Definition and purpose

Total Blocking Time measures the aggregate duration of all long tasks — JavaScript or other main-thread tasks exceeding 50 milliseconds — that occur between the timeline markers of First Contentful Paint and Time to Interactive. The purpose is to estimate how much time a page blocks the main thread and therefore delays the processing of user input events such as clicks, typing, or scrolls. TBT was created to bridge the gap between paint-centric metrics used by PageSpeed Insights and interaction-centric expectations promoted by accessibility and UX groups in organizations like W3C and IETF.

Measurement and calculation

TBT is calculated by summing the blocking portions of long tasks: for any task longer than 50 ms, the task’s duration minus 50 ms is included in the TBT total. The measurement window begins at First Contentful Paint and ends at Time to Interactive (or when the main thread becomes reliably responsive in synthetic tests). Data sources for calculation include browser performance traces captured by tools such as Chrome DevTools, Lighthouse, and Selenium-based tracing harnesses. In lab conditions, tracing protocols from Chromium provide timestamps for task start and end, enabling precise aggregation; in field conditions, similar estimates derive from the PerformanceObserver API used by Real User Monitoring vendors like New Relic, Datadog, and Dynatrace.

Impact on user experience and performance

A high TBT correlates with poor perceived responsiveness and can predict slow reaction to user input; sites with elevated TBT often exhibit lag during click or keyboard events, frustrating users on platforms including Android, iOS, and desktop operating systems like Windows and macOS. Research from organizations such as Google Research and usability groups at Nielsen Norman Group links blocking behavior to increased bounce rates and reduced conversion on commercial properties like Amazon, eBay, and Walmart-powered storefronts. Search engines and indexing systems, exemplified by Google Search updates, increasingly consider performance signals, and teams at Shopify and Squarespace emphasize TBT reduction to improve Core Web Vitals and user satisfaction.

Influencing factors and causes

Primary causes of elevated TBT include large JavaScript bundles from frameworks like React, Angular, Vue.js, and Svelte, heavy use of third-party scripts such as advertising and analytics providers like Google Ads, Facebook Pixel, and DoubleClick, and synchronous work triggered during initial rendering by tools like Webpack or Rollup. Other contributors include complex runtime tasks produced by libraries from jQuery extensions, polyfills required for older browsers such as Internet Explorer, and excessive use of inline scripting patterns advocated in some legacy applications at companies like Adobe or Oracle. Platform-specific runtime behaviors in V8 and SpiderMonkey engines, as well as thread scheduling in Linux and Darwin kernels, can modulate how long tasks block the main thread.

Optimization strategies and best practices

Strategies to lower TBT focus on reducing long tasks and deferring noncritical work. Tactics include code-splitting and dynamic import patterns used by teams at Facebook and Twitter, deferring or lazy-loading third-party scripts as practiced by Pinterest and TripAdvisor, offloading work to Web Workers pioneered in projects like Google Maps and Figma, and minimizing main-thread JavaScript through tree-shaking with tools like Rollup and esbuild. Prioritization techniques—critical CSS extraction used by New York Times and preloading patterns leveraged by Netflix—help move important work earlier while postponing heavy computations. Adopting modern bundlers and transpilers, avoiding synchronous XHR during load (a concern in legacy Drupal and WordPress integrations), and applying performance budgets advocated by Yahoo and Smashing Magazine also reduce TBT.

Tools and diagnostics

Diagnostics for TBT are available in Lighthouse reports, the Chrome User Experience Report, and trace viewers within Chrome DevTools and Firefox Developer Tools. Third-party services like WebPageTest, GTmetrix, SpeedCurve, and APM vendors including New Relic and Datadog expose TBT as a metric alongside waterfall charts and flame graphs. Developers use tracing analysis, long-task APIs observable via PerformanceObserver, and bundler analysis plugins from Webpack and Parcel to identify hot spots; stack traces shown in DevTools, sampling profilers from V8, and CPU throttling tests emulate constrained environments found on devices like iPhone SE and low-end Android phones to reproduce blocking issues.

Category:Web performance metrics