Was ist Total Blocking Time?
Kennst du das? Die Seite ist schon zu sehen, du tippst auf das Menü — und nichts passiert. Eine Sekunde später klappt es plötzlich auf. Genau diese Hänger misst Total Blocking Time (TBT).
Der Browser erledigt fast alles in einem einzigen Arbeitsstrang, dem Haupt-Thread: Seite aufbauen, JavaScript ausführen, auf Klicks reagieren. Läuft dort eine Aufgabe länger als 50 Millisekunden, spricht man von einer langen Aufgabe. Solange sie läuft, muss jeder Klick warten.
TBT addiert, wie lange der Haupt-Thread beim Laden auf diese Weise blockiert ist — vom ersten sichtbaren Inhalt (First Contentful Paint) bis zu dem Moment, in dem die Seite verlässlich bedienbar ist (Time to Interactive).
Wie wird TBT berechnet?
Der Trick: Von jeder langen Aufgabe zählt nur der Teil über 50 Millisekunden. Eine Aufgabe mit 70 ms blockiert also 20 ms.
Total Blocking Time
TBT = Summe aller (Aufgabendauer − 50 ms) zwischen FCP und TTI
Beispiel von web.dev: Aufgaben mit 250, 90, 35, 30 und 155 ms → blockierend 200 + 40 + 0 + 0 + 105 → TBT = 345 ms
Warum so umständlich? Weil viele kurze Aufgaben harmlos sind. Drei Aufgaben à 51 ms ergeben nur 3 ms TBT. Eine einzige Aufgabe von 10 Sekunden ergibt 9.950 ms — und genau die spürt dein Besucher.
Lighthouse
Grün bis
Handy
200 ms
Desktop
150 ms
Rot wird es auf dem Handy ab 600 ms, am Desktop ab 350 ms. Im Lighthouse-Performance-Score zählt TBT seit Lighthouse 10 mit 30 % — mehr als jede andere Messgröße. Largest Contentful Paint und Cumulative Layout Shift kommen auf je 25 %.
Wie steht das Netz da?
Schlecht, und es wird schlechter. Laut Web Almanac 2025 von HTTP Archive liegt die mittlere TBT auf dem Handy bei 1.916 Millisekunden — 58 % mehr als 2024. Nur jede zehnte Mobilseite schafft 127 ms oder weniger. Am Desktop liegt der Mittelwert bei 92 ms.
Das Paradox: Im selben Zeitraum wurde INP bei echten Nutzern besser, 77 % der Seiten haben mobil einen guten Wert. Die Autoren deuten das so, dass Seiten insgesamt mehr JavaScript ausführen. TBT misst unter einer gedrosselten Handy-Simulation, deshalb fallen die Werte so hart aus.
Beispiele aus der Praxis
Case A · Nachrichtenportal
The Economic Times
3.260 → 120 ms
TBT im Labor
−50 %
Absprünge
Drittanbieter-Bibliotheken nachgeladen, Skripte in Hintergrund-Prozesse verschoben, ungenutzten Code entfernt
Fallstudie auf web.dev (2023), Unternehmensangaben. Die Seitenaufrufe auf den Themenseiten stiegen um 43 %.
Case B · Werbenetzwerk
Taboola
712 → 206 ms
Blockierzeit durch Drittskripte
−36 %
INP (bis zu)
Lange Aufgaben im eigenen Skript in kleine Häppchen zerlegt
Fallstudie auf web.dev (2024). Gemessen ist nur der Anteil der Drittanbieter-Skripte, nicht die ganze Seite.
Häufige Fehler
Fehler 1 · TBT für ein Rankingsignal halten
Google nutzt für das Ranking die Felddaten aus dem Chrome UX Report, und dort zählt INP. TBT ist dein Werkzeug zur Fehlersuche, nicht die Note.
Fehler 2 · Einem einzelnen Lighthouse-Lauf glauben
Werbung, A/B-Test-Skripte, Browser-Erweiterungen und Virenscanner verschieben den Wert von Lauf zu Lauf. Miss mehrmals, im Inkognito-Fenster, und vergleich den Mittelwert.
Fehler 3 · Handy- und Desktop-Grenzen verwechseln
200 ms gilt für das Handy. Am Desktop ist Lighthouse strenger und vergibt Grün nur bis 150 ms.
Fehler 4 · Jedes Tool einfach dazupacken
Chat-Widget, Heatmap, drei Pixel, Video-Einbettung: Jedes fremde Skript will den Haupt-Thread. Auf Mobilseiten kamen 2024 im Mittel 375 KB JavaScript von fremden Servern — mehr als doppelt so viel wie vom eigenen.
So senkst du deine TBT
- Skripte ausmisten: Was niemand mehr auswertet, fliegt raus — auch im Google Tag Manager. Google beobachtet einen Zusammenhang zwischen großen Tag-Manager-Containern und schlechter Reaktionszeit.
- Später laden: Skripte mit „defer“ oder „async“ einbinden, damit sie den Aufbau nicht blockieren.
- Platzhalter statt Einbettung: Ein Vorschaubild für das YouTube-Video wiegt rund 3 KB, der echte Player rund 540 KB. Den lädst du erst beim Klick.
- Ungenutztes JavaScript entfernen: Auf Mobilseiten waren 2024 im Mittel 44 % des geladenen JavaScripts ungenutzt.
- Lange Aufgaben zerlegen: Für Entwickler — große Rechenblöcke in kleine Häppchen teilen, damit der Browser zwischendurch Klicks annimmt.
Häufige Fragen
Was ist ein guter TBT-Wert?
In Lighthouse auf dem Handy unter 200 Millisekunden, am Desktop unter 150 Millisekunden. Auf dem Handy gilt ab 600 ms Rot, am Desktop ab 350 ms.
Ist TBT ein Core Web Vital?
Nein. Das Core Web Vital für Reaktionsfähigkeit ist Interaction to Next Paint (INP), gemessen bei echten Besuchern. TBT ist der Laborwert in Lighthouse, der Probleme mit INP oft vorab anzeigt.
Wie stark zählt TBT im Lighthouse-Score?
Seit Lighthouse 10 mit 30 %, so viel wie keine andere Messgröße. Wer seinen Performance-Score verbessern will, kommt an TBT nicht vorbei.
Warum ist meine TBT auf dem Handy so viel höher als am Desktop?
Lighthouse simuliert auf dem Handy einen gedrosselten, langsameren Prozessor. Dasselbe JavaScript braucht dort viel länger. Im Web Almanac 2025 liegt die mittlere TBT mobil bei 1.916 ms, am Desktop bei 92 ms.
Was treibt TBT typischerweise hoch?
Viel JavaScript: Tracking-Pixel, Tag Manager, Chat-Widgets, eingebettete Videos, Werbung und schwere Themes oder Page Builder. Fremde Skripte sind fast immer die größte Baustelle.
