How to reduce Total Blocking Time (TBT)
TBT adds up every moment the page is frozen by JavaScript while loading. Under 200 ms keeps the page responsive. It is the lab stand-in for INP.
Step by step, with screenshots: Total Blocking Time: find the long tasks and cut main-thread work →
Check your own site
Runs this check and the other 192, free, in about 45 seconds.
Or run only this check with the free Website speed comparison or the free Bulk PageSpeed Insights.
What it is
Total Blocking Time (TBT) is the total time a page's main thread was blocked for long enough to stop it responding to input while the page loaded. For every task longer than 50 ms, the part above 50 ms is added up, between First Contentful Paint and the point where the page becomes reliably interactive.
In a Lighthouse mobile test, TBT is good at 200 ms or less and poor above 600 ms. It carries 30 % of the Lighthouse performance score, more than any other metric, and it is the lab stand-in for Interaction to Next Paint, which only real visitors can produce. getReport measures it in a throttled mobile Lighthouse run, so it is higher than you would see on a fast laptop.
What a passing site looks like
- Total Blocking Time: passesfail · −30 ptseffort L
Total Blocking Time
Why it matters. TBT adds up every moment the page was too busy running JavaScript to respond to a tap. It is the lab stand-in for INP and the heaviest-weighted Lighthouse metric.
- Remove or defer JavaScript that is not needed for the first screen (defer, async, or load on interaction).
- Split long tasks (> 50 ms) into smaller chunks; move heavy work to a web worker.
- Audit third-party tags: chat widgets, tag managers and A/B tools are the usual culprits.
Questions people ask
How do I reduce Total Blocking Time on WordPress?
Cut and delay JavaScript. Deactivate plugins you do not use, stop page builders, sliders and pop-ups loading on pages that do not need them, and delay chat widgets, social embeds and marketing tags until the visitor interacts. Performance plugins can defer or delay scripts, but test forms and checkout afterwards, since delaying the wrong script breaks features.
What is a good Total Blocking Time?
200 ms or less in a Lighthouse mobile test is good, 200 to 600 ms needs improvement and above 600 ms is poor. Lighthouse simulates a mid-range phone with a slowed-down processor, so desktop tests show much lower numbers. If your mobile TBT is green, visitors on typical phones will rarely feel the page freeze while it loads.
How do I reduce Total Blocking Time?
Ship less JavaScript and split what remains. Remove unused code and third-party tags, load scripts with defer, move non-essential features to load after the page is interactive, and break long functions into smaller tasks so the browser can respond between them. The report lists long tasks and third-party blocking time, which show the biggest offenders.
Is Total Blocking Time a Core Web Vital?
No. TBT is a lab metric that Lighthouse uses; the Core Web Vitals are LCP, INP and CLS, measured on real visitors. TBT still matters because it predicts INP: a page that blocks the main thread for seconds while loading usually responds slowly to taps and clicks as well.