Total blocking time on 24 homepages: only 2 clear the 200 ms bar

FIELD TEST · 2026-09-30 · 24 homepages · single Lighthouse run

Sample and method: 24 homepages, including our own four sites, each loaded once by Lighthouse 13.5.0 in its mobile configuration on 2026-09-30, and we read the total blocking time audit from each JSON report. One run per site, no averaging, no repeat.

Total blocking time is the lab number that stands in for responsiveness when no real user is on the page, and on this sample it was mostly terrible. Only two of the 24 homepages came in under the 200-millisecond bar that web.dev sets for the metric. The median homepage blocked its main thread for about 6.7 seconds, and 21 of the 24 were over 500 milliseconds. The worst was 22.4 seconds.

How we measured it

Total blocking time is defined as the sum, after first contentful paint, of how long each long task ran past 50 milliseconds, where a long task is any task on the main thread longer than 50 milliseconds (web.dev, read 2026-09-30). Lighthouse computes it against a fixed mobile device and a throttled network, so the numbers are comparable to each other even though none of them is a user's real experience.

We ran one headless Lighthouse per host with only the loading audits enabled, and we kept the raw value rather than the rounded one. The 24 hosts are the panel we have used for other surveys, minus the sites that refuse an automated browser, plus our own four. Each report is a single load, and a single load is the whole sample for that site.

The total blocking time results: two homepages passed the bar

The published bar for this metric is under 200 milliseconds on average mobile hardware. Two sites cleared it. One is a static encyclopaedia page, and the other is a framework site that happened to load almost nothing blocking during our run. Everything else missed, several of them by an order of magnitude.

The spread is the story more than the top of the list. The gap between the best and worst homepage here is over 22 seconds of blocking time on the same simulated device, which means the metric is not measuring the network or the hardware — it is measuring how much JavaScript each team chose to run before anyone asked for it.

Total blocking time is not how slow your page is. It is how much of the main thread your page decided to use before the visitor did anything.

What the numbers do not tell you

This measures blocking, not experience, and the two are not the same thing. A page can block the main thread for seconds and still feel fine to someone who never interacts during that window. A page can show a low blocking time and still feel slow if the one button a user taps lands in a bad moment. The metric web.dev actually documents for responsiveness is interaction to next paint, and total blocking time is a lab proxy for it, not a substitute (Chrome for Developers, read 2026-09-30). If you want the metric itself, interaction to next paint is the chapter for that.

The other limit is the sample. Every number above is one load, and Lighthouse runs are noisy: move the same site to a different machine or a different day and the value can change by thousands of milliseconds. We did not run each site twice, so we cannot tell you how stable any single reading is. What survives the noise is the shape — a handful of sites in the low hundreds, a long tail in the thousands — and that shape is consistent with how these sites are built.

What this means for you

One command gives you your own number, and it needs no account.

npx lighthouse https://example.com/ \
  --only-audits=total-blocking-time \
  --output=json --output-path=tbt.json --quiet

• Read the field number first if you have one. Blocking time explains a bad interaction result; it does not replace it.
• Treat the 200 ms line as a target for the tap a user actually makes, not for the load.
• Do not compare your score to this table across devices. Our numbers are all one machine on one day.
• Do not ship more JavaScript to fix a slow interaction. Most of the time the fix is shipping less.

Common questions

How did you measure this?

One headless Lighthouse run per homepage on 2026-09-30, mobile configuration, reading the total-blocking-time audit from the JSON output. No repeats, no averaging, no field data. The raw reports are saved per host, and the sample is 24 pages of one type: homepages.

Is total blocking time a ranking factor?

No, and neither is the Core Web Vital it stands in for, beyond the general role page experience plays. The reason to care is that a page which blocks for seconds cannot answer a tap quickly, and tapping is what most visitors do.

Why is my number different from PageSpeed Insights?

Because PageSpeed Insights can show field data from real users, and a local Lighthouse run cannot. When the two disagree, the field number is the one that describes your visitors, and this lab number only helps you explain it. For the loading metric beside this one, see largest contentful paint.

Should I optimise total blocking time or interaction to next paint?

Optimise the interaction one if you can measure it. Blocking time is what you reach for when you only have a lab, and it usually points at scripts worth cutting either way. If you are still deciding whether any of this is worth the week, does page speed affect SEO is the honest answer we would give.

Next step

The number is easy to get and hard to argue with. Take your own, find the scripts that run on load, and cut the ones nobody would miss. Watching that blocking time across the pages people land on is part of what QueryWin works on.