Total Blocking Time (TBT)

Die Total Blocking Time, kurz TBT, gibt an, wie lange der Haupt-Thread des Browsers während des Ladens durch lange Tasks blockiert ist. In dieser Zeit sieht die Seite fertig aus, reagiert aber nicht auf Klicks oder Eingaben. Die TBT ist eine reine Laborkennzahl und hat im Lighthouse-Performance-Score das größte Gewicht aller Metriken.

Aus den Messungen von PerfDelta: Im mobilen Labortest erreichen 22 % von 4.075 Startseiten bei Total Blocking Time einen guten Wert, 57 % liegen im schlechten Bereich. Der Median liegt bei 771 ms, die mittlere Hälfte zwischen 245 ms und 1671 ms. Mehr dazu im Datenblock unten.

TBT-Berechnung: Nur der Anteil über 50 ms zählt

Der Browser erledigt JavaScript, HTML-Parsing, Stilberechnung und Layout auf einem einzigen Haupt-Thread. Solange dort eine Aufgabe läuft, muss jede Eingabe warten. Als lange Task gilt jede Aufgabe, die länger als 50 Millisekunden dauert.

In die TBT fließt nicht die volle Dauer ein, sondern nur der Teil oberhalb von 50 ms. Eine Task von 70 ms steuert also 20 ms bei, eine Task von 45 ms gar nichts. Lighthouse addiert diese Anteile für alle langen Tasks in einem festen Zeitfenster.

Ein Beispiel mit vier Tasks während des Ladens:

Task	Dauer	Blockierzeit
Haupt-Bundle ausführen	180 ms	130 ms
Hydration des Frameworks	95 ms	45 ms
Tracking-Skript	70 ms	20 ms
Kleiner Event-Listener	30 ms	0 ms

Die Tasks laufen zusammen 375 ms, die TBT beträgt aber 195 ms. Die Kennzahl bildet also die Wartezeit ab, die ein Besucher bei einer Eingabe tatsächlich spüren würde.

Messfenster der TBT: zwischen FCP und Time to Interactive

Gezählt werden nur Tasks ab dem First Contentful Paint, also ab dem Moment, in dem erstmals Inhalt sichtbar wird. Das Fenster endet mit der Time to Interactive. Das ist der Zeitpunkt, nach dem der Haupt-Thread fünf Sekunden lang ohne lange Tasks bleibt und höchstens zwei Netzwerkanfragen offen sind. Schwere Skripte, die kurz nach dem ersten sichtbaren Inhalt starten, treffen die TBT deshalb voll.

Guter TBT-Wert: 200 ms mobil, 150 ms am Desktop

Lighthouse bewertet die TBT für mobile und Desktop-Tests mit unterschiedlichen Grenzwerten:

Bewertung	Mobil	Desktop
Gut	bis 200 ms	bis 150 ms
Verbesserungswürdig	200 bis 600 ms	150 bis 350 ms
Schlecht	über 600 ms	über 350 ms

Im mobilen Test simuliert Lighthouse eine langsamere CPU. Derselbe Code erzeugt dort längere Tasks, weshalb eine Seite am Desktop grün und mobil rot sein kann. Maßgeblich für die Optimierung ist in der Regel der mobile Wert.

Gewichtung im Lighthouse-Score: TBT zählt 30 %

Seit Lighthouse 10 setzt sich der Performance-Score aus fünf Laborwerten zusammen: Total Blocking Time 30 %, Largest Contentful Paint 25 %, Cumulative Layout Shift 25 %, First Contentful Paint 10 % und Speed Index 10 %. Die TBT ist damit der größte Einzelhebel. Eine Seite mit schnellem LCP und stabilem Layout kann durch viel JavaScript trotzdem einen mittelmäßigen Pagespeed-Score erhalten.

TBT und INP: Laborersatz für die Reaktionsfähigkeit

Die TBT gehört nicht zu den Core Web Vitals. Für die Reaktionsfähigkeit steht dort Interaction to Next Paint, gemessen an echten Interaktionen realer Nutzer. Ein Labortest kennt keine Klicks und kann INP daher nicht messen. Die TBT dient als Näherung, weil ein blockierter Haupt-Thread die häufigste Ursache langsamer Interaktionen ist.

Deckungsgleich sind die beiden Werte nicht. Die TBT betrachtet nur die Ladephase, INP dagegen alle Interaktionen während des gesamten Besuchs. Eine gute TBT bei schlechtem INP im Feld deutet auf langsame Event-Handler oder aufwendiges Neurendern nach dem Laden hin. Eine hohe TBT ist dagegen ein klares Warnsignal für den INP, und die Maßnahmen sind weitgehend dieselben.

Ursachen hoher TBT: JavaScript und Drittanbieter

• Große JavaScript-Bundles: Jedes Skript muss geparst, kompiliert und ausgeführt werden, auch wenn die aktuelle Seite den Großteil des Codes gar nicht braucht.
• Skripte von Drittanbietern: Tag-Manager, Webanalyse, Werbung, Chat-Widgets und Consent-Banner laufen auf Ihrem Haupt-Thread, meist direkt beim Laden.
• Hydration in JavaScript-Frameworks: Serverseitig gerenderte React- oder Vue-Seiten bauen den Komponentenzustand im Browser neu auf und hängen Event-Handler an. Auf umfangreichen Seiten entsteht dabei oft eine einzige lange Task.
• Aufwendige Arbeit im Haupt-Thread: Ein sehr großes DOM, teure Layout-Berechnungen und synchrone Schleifen über große Datenmengen verlängern Tasks zusätzlich.

Lange Tasks finden mit Lighthouse und DevTools

Im Lighthouse-Bericht listet die Diagnose „Lange Aufgaben im Hauptthread vermeiden“ (englisch „Avoid long main-thread tasks“) die längsten Tasks mit Startzeit und Dauer. „JavaScript-Ausführungszeit verringern“ („Reduce JavaScript execution time“) zeigt, wie viel CPU-Zeit jedes Skript beansprucht. Welche externen Anbieter den Haupt-Thread blockieren, weist die Diagnose zum Einfluss von Drittanbieter-Code aus.

Genauer wird es im Performance-Panel der Chrome DevTools. Zeichnen Sie einen Seitenaufruf mit gedrosselter CPU auf. Lange Tasks tragen in der Main-Spur eine rote Markierung, und ein Klick darauf zeigt das verantwortliche Skript samt Funktion. Im Browser lassen sich lange Tasks außerdem protokollieren:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Lange Task:', Math.round(entry.duration), 'ms');
  }
}).observe({ type: 'longtask', buffered: true });

Total Blocking Time senken: Maßnahmen mit Code

Lange Tasks aufteilen und den Haupt-Thread freigeben

Teilen Sie umfangreiche Arbeit in kleine Stücke und geben Sie dem Browser dazwischen die Kontrolle zurück. Dafür gibt es scheduler.yield(), für ältere Browser dient setTimeout als Ersatz:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function verarbeite(eintraege) {
  for (const eintrag of eintraege) {
    rendere(eintrag);
    await yieldToMain(); // jeder Schritt wird eine eigene kurze Task
  }
}

Die Gesamtarbeit bleibt gleich, doch statt einer langen Task entstehen viele kurze, die jeweils unter 50 ms bleiben und damit keine Blockierzeit erzeugen.

Drittanbieter-Skripte verzögern oder entfernen

Prüfen Sie jedes eingebundene Tag auf seinen Nutzen und entfernen Sie alles, was niemand auswertet. Den Rest laden Sie mit defer oder async oder erst nach dem Laden der Seite. Für Chat-Widgets und Videoplayer eignet sich eine leichte Fassade, die das eigentliche Skript erst beim Klick nachlädt.

Weniger JavaScript ausliefern durch Code-Splitting

Laden Sie nur den Code, den die aktuelle Seite braucht, und holen Sie den Rest bei Bedarf per dynamischem Import nach:

button.addEventListener('click', async () => {
  const { oeffneGalerie } = await import('./galerie.js');
  oeffneGalerie();
});

Wie Sie ungenutzten Code aufspüren, beschreibt der Leitfaden Nicht verwendetes JavaScript reduzieren.

Rechenarbeit in Web Worker auslagern

Aufgaben ohne DOM-Zugriff, etwa das Verarbeiten großer JSON-Antworten oder das Filtern von Daten, laufen in einem Web Worker auf einem eigenen Thread. Der Haupt-Thread bleibt für Eingaben frei.

Hydration reduzieren

Hydrieren Sie nur die interaktiven Teile einer Seite. Islands-Architekturen, partielle Hydration und Server Components halten statische Inhalte aus dem Client-Bundle heraus.

TBT in WordPress, Shopify und Next.js

WordPress: Häufige Ursachen sind Plugins, die ihre Skripte auf jeder Seite laden, und Page-Builder. Deaktivieren Sie überflüssige Plugins und nutzen Sie die Option zum Verzögern von JavaScript in Ihrem Caching-Plugin. Testen Sie danach Formulare und Menüs, da verzögerte Skripte sie stören können.

Shopify: Apps binden eigene Skripte ein, und deinstallierte Apps hinterlassen manchmal Code im Theme. Entfernen Sie ungenutzte Apps und prüfen Sie das Theme auf verwaiste Snippets.

React und Next.js: Laden Sie Komponenten unterhalb des sichtbaren Bereichs mit next/dynamic oder React.lazy. Im App Router bleiben Komponenten ohne Zustand und Event-Handler Server Components, und Drittanbieter-Skripte binden Sie über next/script mit der Strategie lazyOnload ein.

Typische Fehler bei der TBT-Optimierung

• Nur am Desktop testen: Die schwächere simulierte CPU im mobilen Test verlängert jede Task.
• Arbeit verschieben statt aufteilen: Eine Task von 400 ms bleibt eine Task von 400 ms, auch wenn sie später im Messfenster startet.
• Tag-Manager für kostenlos halten: Auch darüber geladene Tags laufen auf dem Haupt-Thread.
• Die TBT als Endziel sehen: Entscheidend ist der INP realer Nutzer, den Google für die Bewertung heranzieht.

Verbesserungen der TBT prüfen

Führen Sie Lighthouse oder PageSpeed Insights mehrfach aus und vergleichen Sie den Median, denn die TBT schwankt zwischen einzelnen Läufen spürbar. Kontrollieren Sie im Performance-Panel, ob die längsten Tasks kürzer geworden sind. Die Wirkung auf echte Besucher zeigt anschließend der INP im Chrome UX Report über das nachlaufende 28-Tage-Fenster.

PerfDelta testet mehrere Seiten Ihrer Website mobil und am Desktop und zeigt Labor- und Felddaten. So erkennen Sie, ob eine hohe TBT mit einem schlechten INP einhergeht. Jede Lighthouse-Empfehlung erscheint in PerfDelta mit geschätzter Einsparung, den betroffenen Dateien und einem Link zum passenden Leitfaden.

Häufige Fragen

Was ist die Total Blocking Time?

Die Total Blocking Time ist die Summe der Blockierzeiten aller langen Tasks im Haupt-Thread zwischen First Contentful Paint und Time to Interactive. Pro Task zählt nur der Anteil über 50 ms, eine Task von 70 ms ergibt also 20 ms.

Welcher TBT-Wert ist gut?

Lighthouse bewertet mobil bis 200 ms als gut und über 600 ms als schlecht. Am Desktop gelten bis 150 ms als gut und über 350 ms als schlecht.

Ist die TBT ein Core Web Vital?

Nein. Die TBT ist eine Laborkennzahl. Das Core Web Vital für die Reaktionsfähigkeit ist Interaction to Next Paint, das im Feld gemessen wird. Die TBT dient im Labor als Näherung dafür.

Wie stark zählt die TBT im Lighthouse-Score?

Die TBT macht 30 % des Lighthouse-Performance-Scores aus und ist damit die am stärksten gewichtete Einzelmetrik.

Wie lässt sich die Total Blocking Time senken?

Lange Tasks aufteilen und den Haupt-Thread freigeben, Drittanbieter-Skripte verzögern oder entfernen, Code-Splitting einsetzen, Rechenarbeit in Web Worker verlagern und die Hydration reduzieren.

Warum schwankt die TBT zwischen zwei Tests?

Schon kleine Zeitunterschiede auf der Testmaschine können eine Task über oder unter die Grenze von 50 ms schieben. Aussagekräftig ist der Median mehrerer Läufe.