TBT Too High: How to Diagnose and Fix It

What this check flags

This fires when Lighthouse reports Total Blocking Time above its "good" band, meaning the main thread spent too long locked up during load and couldn't respond to input. TBT is a lab metric, not one of the three Core Web Vitals, but it's the lab proxy for INP, the responsiveness vital Google actually ranks with, so a high TBT is your early warning that real users will find the page sluggish to tap.

What TBT measures, and why it stands in for INP

During load, any main-thread task that runs longer than 50 milliseconds is a "long task", and everything past that 50ms mark is blocking time, the window where a tap or click would just sit there unanswered. TBT sums all that blocking time between First Contentful Paint and Time to Interactive. Under 200ms is good, 200 to 600 needs improvement, above 600 is poor, on Lighthouse's mobile profile. INP can't be measured in the lab because it needs a real person clicking things, so TBT is the deterministic stand-in: drive TBT down and INP almost always follows, because they share the same root cause, a main thread buried in JavaScript.

A real example, and the fix

A page with 900ms of TBT. The trace shows one monster task: a 700ms chunk where a third-party analytics bundle and the site's own framework both boot synchronously the moment the page loads, freezing everything. Two moves. First, defer the third-party script so it doesn't compete during the critical window:

<!-- Before: runs immediately, blocks the main thread on load -->
<script src="https://cdn.example.com/analytics.js"></script>

<!-- After: loads after the page is interactive -->
<script src="https://cdn.example.com/analytics.js" defer></script>

Second, break the site's own long task into chunks so the browser can breathe between them and answer input:

// Before: one 400ms blocking loop
processAll(items);

// After: yield to the main thread between chunks
async function processAll(items) {
  for (const item of items) {
    process(item);
    await new Promise(r => setTimeout(r)); // yields, lets input through
  }
}

Deferring the third party clears the biggest single block, and yielding turns one 400ms task into many sub-50ms ones that no longer count against TBT. Real-world, that 900ms drops under 200 and INP follows it down.

Where TBT sits among the responsiveness metrics

How to detect it

1. PageSpeed Insights, Lighthouse section. TBT is one of the five lab metrics with its own score. Below it, "Reduce JavaScript execution time" and "Minimize main-thread work" name the exact scripts eating your budget, see the PageSpeed Insights reference.
2. DevTools Performance panel. Record a load with 4x CPU throttle. Long tasks show up flagged with a red corner in the flame chart; click one to see the exact call stack that's blocking, which points straight at the offending bundle.
3. Field cross-check with INP. Since TBT is the proxy, confirm the real impact in CrUX and the Search Console INP report. A high TBT with a passing field INP is lower priority than one where INP is also failing.
4. Search Console INP report. There's no TBT field report, INP is the field-side signal, so filter for "INP issue: longer than 200ms" to see which templates carry the real-user cost.

How to fix it

1. Defer and delay third-party scripts. Analytics, chat widgets, and tag managers are usually the biggest blockers; load them after the page is interactive, per third-party script management.
2. Break up long tasks. Yield to the main thread inside heavy loops so input can slip through between chunks; this is the core move in minimize main-thread work.
3. Ship less JavaScript. Code-split, tree-shake, and cut what you don't need. The remove unused JavaScript check finds the dead weight.
4. Hydrate lazily. On framework sites, defer or island-hydrate below-the-fold components so the whole app isn't booting at once on load.

The 50ms line is the whole game

Everything about TBT comes back to that 50-millisecond threshold. A task under 50ms is invisible to the metric; a task at 250ms contributes 200ms of blocking. So the goal isn't always "do less work", it's "do the same work in smaller pieces". A 400ms task that you split into ten 40ms tasks contributes zero to TBT even though the total computation is identical, because the browser gets ten chances to answer a tap in between. That reframing changes how you fix things: before you go hunting for code to delete, look for one big synchronous block you can chunk with a yield. It's usually faster to ship and it's exactly what improves real-user INP, because INP is measured on individual interactions that need those gaps to squeeze through.

FAQ

Is TBT a Core Web Vital?

No. The three are LCP, INP, and CLS. TBT is a Lighthouse lab metric that serves as the load-time proxy for INP, which is the responsiveness vital that actually feeds rankings.

My TBT is high but my field INP passes. Do I still fix it?

Lower priority, but don't ignore it. TBT only measures blocking during load, while INP covers the whole session; a passing INP means real users aren't feeling it yet, but a heavy main thread is fragile and one more script can tip it.

Why is TBT worse on mobile than desktop?

Same JavaScript, far weaker CPU. A task that runs in 50ms on your laptop can take 300ms on a mid-range phone, so mobile TBT balloons. Always fix against the mobile profile.

Does deferring scripts hurt analytics or ads?

Rarely in any way that matters. Most analytics tolerate a short delay fine, and the tradeoff, a page that responds to taps instead of freezing, is almost always worth a couple hundred milliseconds of later tracking.