Quick answer
Total blocking time (TBT) is a lab metric that sums, for every main-thread task longer than 50 ms between first contentful paint and Time to Interactive, the time beyond 50 ms. It indicates how unresponsive a page is during load.
Formula: TBT = Σ (long task duration − 50 ms)
What is total blocking time?
Total blocking time (TBT) measures how long a page's main thread was blocked during load, making the page unable to respond to input. It adds up the "blocking" portion of every long task (a task over 50 ms) between first contentful paint and Time to Interactive.
TBT = Σ (duration of each long task − 50 ms)The 50 ms allowance exists because a task under 50 ms still lets the browser respond to a click within roughly 100 ms, which feels instant. Anything beyond that is time the user would have to wait.
TBT is a lab metric: Lighthouse and similar tools measure it in a controlled load. It is the lab counterpart of field responsiveness metrics such as Interaction to Next Paint.
Worked example
Five main-thread tasks run after first contentful paint (sample trace):
| Task | Duration | Blocking time (duration − 50 ms) |
|---|---|---|
| Framework hydration | 250 ms | 200 ms |
| Analytics and tag manager | 90 ms | 40 ms |
| Style recalculation | 35 ms | 0 ms (not a long task) |
| Third-party chat widget | 120 ms | 70 ms |
| Image carousel init | 60 ms | 10 ms |
| Total | 555 ms of work | TBT = 320 ms |
Splitting hydration into five 50 ms chunks would remove 200 ms of TBT on its own, without doing any less work, because each chunk lets the browser handle input in between.
TBT thresholds
Lighthouse scores TBT on mobile roughly as:
| Rating | TBT (mobile) |
|---|---|
| Good | 0–200 ms |
| Needs improvement | 200–600 ms |
| Poor | over 600 ms |
In Lighthouse 10 and later, TBT carries 30% of the performance score, more than any other metric.
TBT, FID and INP
| Metric | Measured | What it captures |
|---|---|---|
| TBT | Lab | Total main-thread blocking during load |
| First input delay (retired 2024) | Field | Delay before the first interaction was handled |
| Interaction to Next Paint | Field (Core Web Vital) | Latency of interactions across the whole visit |
A high TBT in the lab is a strong hint that real users will see poor INP, especially on slower phones. But TBT only covers the load phase; INP also catches slow interactions later on.
How to reduce TBT
- Break up long tasks. Split work into chunks and yield to the main thread (for example with
scheduler.yield()orsetTimeout). - Ship less JavaScript: remove unused code, code-split by route, avoid large polyfills.
- Defer or lazy-load third-party scripts such as chat widgets, A/B testing and tag managers until after interaction or idle time.
- Hydrate less: partial or progressive hydration, server components, islands.
- Move heavy work off the main thread into web workers.
- Avoid layout thrashing from reading and writing layout properties in loops.
In TapCub
TBT needs a controlled lab run, so TapCub, which measures real visits, does not report it. Its performance report shows the field metrics that TBT predicts: INP for responsiveness, plus LCP, CLS, time to first byte and first contentful paint, at P75 or P95 by page, device and browser. Use Lighthouse to find long tasks during development, then check INP in TapCub to confirm real users feel the difference. The TapCub script itself is small and loads without blocking parsing. See Core Web Vitals and synthetic monitoring.
Sources
- web.dev. Total Blocking Time (TBT).
- Chrome for Developers. Lighthouse: Total Blocking Time.
- web.dev. Optimize long tasks.
Was this explanation clear?
We use your answers to fix and expand this page.
Couldn’t send. Please try again in a minute.
Thanks for the feedback. We’ll use it to improve this page.You’ve already sent feedback on this page. Thanks.
Technical Engineer
Focuses on tracking code, SDKs, and API integrations, with practical guidance on implementation checks and troubleshooting.