Total Blocking Time (TBT) measures how long the main thread was blocked by long tasks between FCP and TTI, long enough that the page could not respond to input. Any task running over 50 ms contributes its overage: a 120 ms task adds 70 ms of blocking time. TBT is the single biggest contributor to the PageSpeed score at 30% weight, and the lab stand-in for how the page will score on the field metric INP.
The 200-millisecond budget
The Good / Needs-work / Poor bands sit in the summary panel. TBT is lab-only, measured under simulated CPU throttling, which is why a site that feels fine on a desktop can score poorly on a throttled mobile run. There is no field equivalent; INP is the real-world signal TBT approximates.
On some platforms it is every single site
Blocking JavaScript is the defect we find most uniformly. In our snapshot of audited sites (2026-07-23), all 30 Wix sites shipped scripts that block the parser and inline scripts that execute mid-render, with no exceptions in either column. All 37 Squarespace sites did too, and between them carried 811 separate inline script blocks in the body.
That uniformity is the useful part. A defect present on 30 of 30 sites is not a mistake somebody made; it is what the platform emits, and no amount of care inside the editor will remove it.
The tools that make this number look better than it is
Some performance plugins defer all JavaScript until a user interaction. WP Rocket’s option delays “the loading of all JavaScript files and inline scripts until there is a user interaction”; Cloudflare’s Rocket Loader defers loading “until after rendering”. A lab run never interacts, so that JavaScript never runs, and TBT drops for a reason the visitor will not enjoy: the phone that does tap and scroll pays the cost the lab skipped.
What fills the main thread
- Large blocking JavaScript bundles, parsed and executed during load, monopolising the main thread before the page can respond.
- Third-party scripts in the
<head>. Tag managers, analytics, chat and ad scripts run long tasks at load; held until the first interaction, they stop blocking. - Any single task over 50 ms. One long task freezes input; breaking the work into chunks keeps the thread free.
- Shipping JavaScript the page never uses. Code that downloads, parses and executes for nothing.
What deferring charges you
- Deferring scripts cuts blocking, but if the LCP element is drawn by that JavaScript, you trade blocking time for a later LCP.
- Pushing work later can move it into TTI. The thread frees up sooner, but the deferred tasks still have to run, so the page can reach TTI later even as blocking time drops.
async/deferchanges execution order, which breaks scripts that assume synchronous, in-order loading.
Our rule is to defer only third-party and non-critical scripts and leave render-critical JavaScript alone, so cutting TBT does not push the largest paint back.
Getting scripts off the load path, in code
- <script src="/bundle.js"></script>
- <script src="/analytics.js"></script>
+ <script src="/bundle.js" defer></script>
+ <script src="/analytics.js" defer></script>How we clear the main thread
WebSpeed defers third-party scripts until the first interaction, delays non-critical inline scripts, and queues jQuery startup work instead of running it all at load, breaking up the long tasks that accumulate into TBT.