Santaji GadeDigital Marketing1 month ago62 Views

Your page looks loaded but clicks do nothing for a moment that's TBT. Here's exactly how it's calculated (with a real worked example), what causes it, and a calculator to check your own long tasks.
Table of Contents
ToggleTBT carries more weight in your Lighthouse score than any other single metric, roughly 30%, yet most website owners have never heard of it. If your page looks fully loaded but clicks seem to do nothing for a moment, this is almost always the metric responsible, and it is measured in a genuinely simple, checkable way.
Total Blocking Time, or TBT, measures the total amount of time between First Contentful Paint and Time to Interactive during which the browser's main thread is blocked by tasks longer than 50 milliseconds, preventing it from responding to clicks, taps, or typing.
We covered the real-user counterpart to this metric in our INP guide. TBT is the lab-based proxy for INP, useful specifically because INP is much harder to measure before a site is live.
weight TBT carries in the overall Lighthouse performance score, the highest of any metric
is the threshold a task must exceed before it starts counting toward this metric
or less is Google's recommended target on average mobile hardware
The formula is simpler than it sounds. For every long task, only the portion beyond the first 50 milliseconds counts.
Adding those three contributions together, 200ms plus 0ms plus 10ms, produces a total blocking time of 210ms for this example page.
Video: "How to Fix Interaction to Next Paint (INP) and Total Blocking Time (TBT) with Brian Jackson" featuring Brian Jackson of Perfmatters, via The Admin Bar — credit to the original creator, via YouTube
This is a genuinely important distinction. Tap through both to see how this metric relates to the official Core Web Vitals.
According to web.dev's official documentation, this metric is a lab-only measurement calculated by Lighthouse during a simulated page load. It is not available in CrUX field data at all, unlike LCP, INP, and CLS.
A low reading here often correlates with a low INP, since both measure symptoms of the same underlying problem: a busy main thread. This makes it a useful early-warning signal before a site accumulates enough real traffic for INP field data to be meaningful.
| Cause | Typical Impact |
|---|---|
| Large JavaScript bundles | A single 500KB file can block the main thread for 1-2 seconds on mobile |
| Third-party scripts | Analytics, chat widgets, ad tags, and A/B testing tools frequently create long tasks |
| Unoptimized framework hydration | React, Vue, or Angular initial hydration can create 200ms+ long tasks on its own |
Enter the duration of up to four long tasks from your Lighthouse or DevTools performance trace to see the total.
Find task durations in Chrome DevTools' Performance panel, under the Main thread section
Enter your task durations above and click calculate.
According to PageSpeed Matters' 2026 guide, three strategies address the underlying cause directly: code-splitting so JavaScript loads on demand, breaking long tasks into smaller chunks using the scheduler.yield() API, and deferring non-critical scripts until after the user actually interacts.
According to Last9's guide to fixing this metric, auditing third-party scripts specifically is often the fastest win, since tag managers, chat widgets, and marketing pixels frequently run unnecessary work on the main thread that the site owner never explicitly requested.
According to PageVitals' guide for website owners, mid-range phones amplify long tasks significantly, so a page that looks fine on desktop often turns out to be genuinely broken-feeling on mobile hardware.
Tracking deltas after every release matters more than watching the absolute number alone. A jump from 150ms to 350ms after a new tag deployment is worth investigating immediately, even if 350ms has not yet crossed into clearly poor territory.
According to BrowserStack's guide to minimizing TBT, Lighthouse remains the most accessible way to measure it, either directly in Chrome DevTools' Lighthouse panel or through PageSpeed Insights, which runs Lighthouse automatically for any submitted URL.
For a more granular breakdown, Chrome DevTools' Performance panel shows every individual long task on the main thread, letting you identify exactly which script or function is responsible for a given block of blocking time, rather than relying on a single aggregated number.
According to SigNoz's complete guide to TBT, values below 200ms on mobile or 150ms on desktop indicate good responsiveness, with the desktop threshold being slightly stricter since desktop hardware is generally more capable.
According to Quattr's guide to measuring and reducing TBT, single-page applications that render entirely client-side tend to show the highest values, since the browser has to download, parse, and execute a large JavaScript bundle before the page becomes interactive at all.
Server-side rendering or static generation avoids much of this problem by handing the browser ready-to-paint HTML upfront.
JavaScript in that scenario only needs to attach event handlers to already-visible content, a far smaller and faster task than building the entire page from scratch on the client.
A single audit rarely stays accurate for long. New marketing scripts, plugin updates, and growing content complexity can all quietly push a previously healthy TBT score back into problematic territory.
Checking Lighthouse scores as part of a pre-launch checklist for any significant site change, rather than only running a review after visitors start complaining, catches TBT regressions while they are still small and easy to isolate.
TBT measures main-thread blocking time between FCP and TTI.
Only the portion of a task beyond 50ms counts toward the total.
Good is 200ms or less; poor is above 600ms.
It carries 30% weight in Lighthouse, more than any other metric.
It is a lab metric only; INP is the real-user equivalent.
Large JS bundles and third-party scripts are the top causes.








