Leitfäden

Was ist Total Blocking Time (TBT)? Die schwerste Metrik im Lighthouse-Score

vuetelemetry
Leitfäden
7 Min. Lesezeit

TBT trägt 30 Prozent des Lighthouse-Performance-Scores, mehr als jede andere Metrik, und ist trotzdem kein Core Web Vital. Was sie zählt, warum nur der Anteil einer Aufgabe über 50 ms gemessen wird, und warum das Aufteilen Ihres JavaScripts mehr bringt als das Verkleinern.

Total Blocking Time ist die Metrik mit dem größten Anteil am Lighthouse-Performance-Score, 30 Prozent, vor LCP und CLS mit je 25. Sie ist zugleich kein Core Web Vital, und diese beiden Tatsachen zusammenzuhalten ist genau der Grund, sie richtig zu verstehen.

Gemessen wird nicht, wie lange Ihre Seite lädt. Gemessen wird, wie lange der Browser zu beschäftigt war, um Ihnen zu antworten.

Was TBT tatsächlich zählt

Autos stehen Stoßstange an Stoßstange mit eingeschalteten Bremslichtern. Ein Fahrzeug, das sich nicht bewegt, hält alles dahinter auf, und genau das tut eine einzelne lange Aufgabe mit dem Haupt-Thread.

Während des Ladens führt der Browser Ihr JavaScript auf dem Haupt-Thread aus, demselben Thread, der Klicks und Tastendrücke verarbeitet. Solange dort Arbeit läuft, kann nichts anderes geschehen. Eine Aufgabe, die den Haupt-Thread länger als 50 Millisekunden belegt, heißt Long Task und ist die Einheit, aus der TBT gebaut ist.

Hier ist der Teil, der überrascht. TBT zählt nicht die ganze Aufgabe, sondern nur den Anteil oberhalb der 50-ms-Schwelle. Eine Aufgabe von 70 ms steuert 20 ms bei. Eine von 45 ms steuert gar nichts bei. TBT ist die Summe dieser blockierenden Anteile aller Long Tasks zwischen First Contentful Paint und dem Moment, in dem die Seite interaktiv wird.

Die 50-ms-Grenze ist nicht willkürlich. Sie liegt ungefähr dort, wo ein Mensch bemerkt, dass die Oberfläche nicht sofort reagiert hat. Die Metrik zählt also die Zeit, in der die Seite spürbar reglos war, nicht die Zeit, die sie mit Arbeiten verbracht hat.

Warum sie 30 Prozent wiegt und trotzdem kein Core Web Vital ist

Lighthouse ordnet TBT in drei Bänder, gemessen auf seinem simulierten Mobilgerät: gut bei 200 ms oder weniger, verbesserungswürdig zwischen 200 und 600 ms, schlecht über 600 ms. Diese Zahlen setzen ein Mittelklasse-Telefon voraus, das bewusst langsamer ist als die Maschine, von der aus Sie testen.

Gut - 200 ms oder weniger
Verbesserungswürdig - zwischen 200 und 600 ms
Schlecht - über 600 ms

TBT ist eine Labormetrik. Sie wird in einem kontrollierten Lauf gemessen, mit festem Geräteprofil und ohne echten Nutzer, und genau deshalb ist sie kein Core Web Vital: die Core Web Vitals sind Feldmetriken aus echten Besuchen. Ihr Feld-Gegenstück ist Interaction to Next Paint, und beide hängen zusammen, ohne dasselbe zu sein.

TBT betrachtet den blockierten Haupt-Thread während des Ladens. INP betrachtet, was tatsächlich geschah, als eine echte Person interagierte, zu einem beliebigen Zeitpunkt des Besuchs. Eine Seite kann ein ordentliches TBT und ein schlechtes INP haben, weil die teure Arbeit später anfällt, beim Öffnen eines Menüs oder beim Setzen eines Filters.

Was sie verschlechtert

Die Ursachen sind fast immer JavaScript, meist in einer von drei Gestalten. Ein großes Bundle muss geparst, kompiliert und ausgeführt werden, bevor irgendetwas anderes laufen kann, und diese Arbeit landet am Stück auf dem Haupt-Thread.

Framework-Hydration ist die zweite häufige Quelle. Serverseitig gerendertes HTML kommt schnell an, dann läuft das Framework den Komponentenbaum ab, um Verhalten anzuhängen, und auf einer großen Seite ist dieser Durchlauf eine einzige lange Aufgabe, genau in dem Moment, in dem der Nutzer am ehesten zu klicken versucht.

Drittanbieter-Skripte sind die dritte und am wenigsten kontrollierte. Tag-Manager, Analyse, Chat-Widgets und Consent-Banner führen jeweils eigene Arbeit auf Ihrem Haupt-Thread aus, nach einem Zeitplan, den Sie nicht setzen, und ihre Kosten tauchen fast nie im Bundle-Budget von irgendjemandem auf.

Aufteilen schlägt Verkleinern

Der Reflex ist, das Bundle kleiner zu machen. Das hilft, ist aber nicht derselbe Hebel, und das ist das Nützlichste, was man über TBT wissen kann. Die Metrik zählt Zeit oberhalb von 50 ms je Aufgabe, also schneidet dieselbe Menge Arbeit, aufgeteilt in viele kurze Aufgaben, weit besser ab als eine lange, bei exakt gleichen Bytes.

Deshalb zählt das Abgeben der Kontrolle. Eine schwere Schleife so zu zerlegen, dass der Browser zwischen den Teilen Eingaben bedienen kann, Berechnungen in einen Web Worker zu verlagern, wo sie den Haupt-Thread gar nicht berühren, und Drittanbieter zu verzögern, bis die Seite benutzbar ist, senken alle das TBT, ohne eine einzige Zeile Logik zu entfernen.

- vuetelemetry

Labor und Feld messen nicht dasselbe

Ein ehrlicher Vorbehalt, bevor Sie auf die Zahl hin optimieren. Ein Laborlauf nutzt ein einziges Geräteprofil und klickt nie irgendwo, TBT kann also gut aussehen, während echte Nutzer auf billigerer Hardware weiter warten. Behandeln Sie es als Diagnose, die Ihnen sagt, wo der Haupt-Thread beschäftigt ist, und sehen Sie in den Felddaten nach, was die Leute wirklich erlebt haben.

Zusammen gelesen beantworten die beiden verschiedene Fragen. TBT sagt Ihnen, dass die Seite beim Laden blockiert war, und ungefähr wie stark. INP sagt Ihnen, ob das für jemanden eine Rolle spielte.

FAQ

Was ist eine gute Total Blocking Time?

200 ms oder weniger in einem Lighthouse-Lauf, der ein simuliertes Mittelklasse-Mobilgerät verwendet. Zwischen 200 und 600 ms gilt als verbesserungswürdig, über 600 ms als schlecht. Da der Lauf gedrosselt ist, ist ein auf Ihrem eigenen Notebook ohne Drosselung gemessener Wert nicht vergleichbar und wirkt meist deutlich besser als die Wirklichkeit.

Ist Total Blocking Time ein Core Web Vital?

Nein. Die Core Web Vitals sind Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift, und sie werden aus echten Besuchen erhoben. TBT ist eine Labormetrik aus einem kontrollierten Lauf, weshalb sie 30 Prozent des Lighthouse-Performance-Scores tragen kann und trotzdem außerhalb des rankingrelevanten Satzes bleibt.

Was ist der Unterschied zwischen TBT und INP?

TBT misst die Blockade des Haupt-Threads während des Ladens, im Labor, ohne interagierenden Nutzer. INP misst, wie lange echte Interaktionen brauchten, um eine sichtbare Reaktion zu erzeugen, zu jedem Zeitpunkt des Besuchs. Sie korrelieren, weil ein beschäftigter Haupt-Thread beiden schadet, aber eine Seite kann bei TBT gut und bei INP schlecht abschneiden, wenn die teure Arbeit nach dem Laden anfällt.

Warum zählt eine Aufgabe von 45 ms gar nichts?

Weil TBT nur den Anteil einer Aufgabe oberhalb von 50 ms zählt. Eine Aufgabe von 45 ms ist keine Long Task und steuert null bei; eine von 70 ms steuert 20 ms bei. Die Schwelle liegt ungefähr dort, wo ein Mensch zu bemerken beginnt, dass die Oberfläche nicht reagiert hat, die Metrik misst also spürbare Reglosigkeit statt Gesamtarbeit.

Wie senke ich die Total Blocking Time?

Teilen Sie die Arbeit auf, bevor Sie versuchen, sie zu entfernen. Dieselbe Menge JavaScript in kurzen Aufgaben schneidet weit besser ab als eine lange: geben Sie zwischen den Teilen an den Browser ab, verlagern Sie Berechnungen in einen Web Worker und verzögern Sie Drittanbieter-Skripte, bis die Seite benutzbar ist. Reduzieren Sie danach, was Sie ausliefern: Code-Splitting, ungenutzte Abhängigkeiten entfernen und die Hydration-Kosten großer Seiten senken.