This translation has not been editorially reviewed yet. The German version is authoritative. Deutsche Fassung
Performance
What is Total Blocking Time, and why doesn't a page respond while loading?
Total Blocking Time (TBT) measures how long a page, while loading, is busy enough with script work that input goes unanswered — Google rates up to 200 milliseconds as good, above 600 milliseconds as poor. In these moments, the page looks finished but doesn't respond to any click. TBT is exactly what turns this hidden freeze into a visible number.
Blocking time is the invisible freeze after loading
A browser has only one main thread per page, on which everything is processed one after another: running scripts, handling input, drawing the screen. If a long script runs, the thread is occupied — the visitor's click has to wait until the script finishes. TBT adds up all these waiting phases during loading. That explains a familiar annoyance: the page looks finished, the menu is visible, but tapping it does nothing for several seconds. The visitor taps again, thinks their device is broken, or gives up — while the page is just quietly working through its scripts.
TBT is the lab approximation for responsiveness
Real visitors' responsiveness (INP) can only be observed in the field — that requires enough actual views over 28 days. New pages and low-traffic pages lack this data. That's where TBT steps in: it's measured in the lab and shows the same cause from a different angle. A page with a high blocking time will give real visitors sluggish responses once they arrive. The Google thresholds: up to 200 milliseconds good, up to 600 needs improvement, above that poor. The audit service collects TBT in the lab via the PageSpeed measurement and uses it as the finding source when no field value for responsiveness is available.
Too much script work is the cause, cleaning up is the fix
High blocking times almost always come from too much or too heavy JavaScript: ad networks, analytics tools, chat widgets, video embeds, and template-builder extensions each bring their own scripts, all of which want to run during loading. Each one looks harmless on its own, but together they choke the main thread — especially on mobile phones with weaker processors. The fix is unglamorous: remove integrations that are no longer used, load remaining scripts only after the visible content, and start extras like chat only once the visitor requests them. The audit report states the measured value and the target value as a clear guide for this clean-up.
- Tap the menu right after your homepage appears and check whether it responds immediately or only after a noticeable pause.
- Have your agency list all embedded third-party scripts, and together remove anything with no demonstrable benefit left.
- Ask for chat widgets, videos, and maps to load only once the visitor actually clicks them.
- Check the blocking time especially in the mobile measurement, since weaker phone processors turn the same amount of script into a much longer freeze.
- Measure again after adding any new tool — every additional integration lengthens the blocking time.
