Was ist der TTFB?

Time to First Byte misst, wie viel Zeit zwischen der Anfrage des Browsers und dem ersten Byte der Antwort vergeht. Das ist keine Ladezeit: Wenn dieses erste Byte eintrifft, ist auf dem Bildschirm noch nichts zu sehen. Es ist der Moment, in dem der Server aufhört zu denken und anfängt zu sprechen.

web.dev nennt als Anhaltspunkt 800 Millisekunden für einen guten Wert und 1.800 als Grenze des Vertretbaren. Anders als die Core Web Vitals ist der TTFB keine Kennzahl, nach der bewertet wird; er ist eine vorgelagerte Diagnose, die vieles von dem erklärt, was danach passiert.

Das verbreitetste Missverständnis ist, ihn für „die Zeit des Servers“ zu halten. In den TTFB fallen der Reihe nach: vorhandene Weiterleitungen, der Start des Service Workers, die DNS-Abfrage, die TCP-Verbindung, die TLS-Aushandlung, das Senden der Anfrage und zuletzt die Arbeit des Servers. Auf vielen langsamen Seiten ist das Backend die schnellste Etappe von allen.

Diese Zusammensetzung erklärt, warum zwei Seiten desselben Servers sehr verschiedene Werte liefern können. Eine direkt angeforderte startet einmal kalt; eine, die über einen alten Link mit 301-Weiterleitung erreicht wird, wiederholt die halbe Kette, bevor sie überhaupt beginnt.

Zwei nahe Verwandte werden regelmäßig mit ihm verwechselt. Die Antwortzeit des Servers ist nur die letzte Etappe des TTFB; die Netzlatenz ist nur eine der mittleren. Der TTFB umfasst beide und alles Übrige vor dem ersten Byte, und genau darin liegt sein Nutzen: Er ist die einzige Messung, die den ganzen Weg abdeckt.

Für einen E-Commerce-Shop mit großem Katalog hat diese Unterscheidung Folgen fürs Budget. Ein teureres Hosting korrigiert die letzte Etappe; ging die Zeit für die DNS-Auflösung eines langsamen Anbieters oder für eine geerbte Sprungkette drauf, kauft das Geld gar nichts.

Eine Weiterleitung fügt nicht „einen Schritt“ hinzu. Sie fügt die ganze Kette davor noch einmal hinzu, häufig gegen eine andere Domain, was DNS-Auflösung und TLS-Aushandlung von vorn erzwingt.

Der klassische Fall ist der alte Link auf http:// ohne www: Der Browser springt zur Fassung mit HTTPS, von dort zu der mit www, und erst dann bekommt er die Seite. Drei vollständige Ketten für einen Besuch, und alle laufen ab, bevor der Nutzer ein einziges Pixel sieht.

Daraus folgt eine Regel für jede Verlinkungsarbeit: immer auf das Endziel verlinken, in der internen Verlinkung wie in Kampagnen. Ein falsch gesetzter Tracking-Parameter, der einen zusätzlichen Sprung auslöst, vervielfacht die Kosten bei jedem bezahlten Klick.

Weiterleitungen verbrauchen außerdem Crawl-Budget: Jeder Sprung ist eine Anfrage, die der Crawler machen muss, um an derselben Stelle anzukommen. Auf einer großen Website konkurriert das mit den Seiten, die er wirklich ansehen soll.

Weiterleitungsketten wachsen von selbst und fast nie durch eine Entscheidung. Sie sammeln sich mit jeder Migration, jeder Änderung der URL-Struktur, jeder Kampagne mit eigener Kurzadresse. Niemand löscht sie, weil jede einzelne funktioniert; die Kosten sieht man auf keinem Bildschirm und erst als Summe im TTFB.

Sie durchzusehen gehört zu den dankbarsten Aufgaben einer Prüfung, weil die Korrektur endgültig ist: Zeigen die Links einmal auf das Endziel, kommt das Problem nicht wieder. Und sie hilft gleichzeitig der Geschwindigkeit, dem Crawl-Budget und der internen Verlinkung — drei Dinge, die selten mit einer einzigen Änderung besser werden.

Der erste Schritt ist, die Etappen zu trennen, denn die Maßnahmen unterscheiden sich je Etappe. Das Netzwerk-Panel des Browsers schlüsselt die Zeit nach DNS-Wartezeit, Verbindung, TLS und Antwortwartezeit auf, und damit weiß man, ob das Problem vor oder im Server sitzt.

Überwiegt die Antwortwartezeit, liegt die Arbeit im Backend: Datenbankabfragen ohne Index, Vorlagen, die bei jedem Aufruf neu erzeugt werden, Aufrufe fremder Dienste innerhalb des Anfragezyklus. Ein Seiten-Zwischenspeicher löst den Fall oft vollständig, weil er aus einer Berechnung ein Lesen macht.

Überwiegt die Verbindung, ist die Entfernung das Problem. Ein Server in Frankfurt bedient einen Besucher aus Santiago mit einer physikalischen Verzögerung, die keine Codeoptimierung beseitigt; dort hilft ein Auslieferungsnetz, das von einem nahen Knoten ausliefert.

Gibt es Weiterleitungen, werden sie zuerst entfernt, weil sie die einzige Etappe sind, die sich ganz streichen statt nur beschleunigen lässt. Danach prüft man in Search Console, ob die Felddaten mitziehen, eingedenk dessen, dass sie Wochen brauchen.

Eine Maßnahme wird übersehen und kostet wenig: nachsehen, ob der Zwischenspeicher dort greift, wo die Leute ankommen. Viele Konfigurationen schließen jede URL mit Parametern automatisch aus, und genau die bekommen den Traffic aus Kampagnen, mitsamt der über den Google Tag Manager gesetzten Markierungen.

Das Ergebnis ist eine Website, die im Test schnell wirkt und für den langsam ist, der über eine Anzeige kommt — meist der teuerste Besucher. Man sollte mit der vollständigen URL messen, Parameter eingeschlossen, und nicht mit der sauberen Fassung, die man von Hand eintippt.

Der TTFB ist die erste der vier Teilzeiten, in die sich der LCP zerlegt. Alles, was hier vergeht, wird vollständig dorthin mitgenommen: Trifft das erste Byte nach einer Sekunde ein, bleiben 1,5 Sekunden zum Laden und Zeichnen des Hauptbilds, wenn man in den guten Bereich will.

Ein hoher TTFB ist deshalb die häufigste Erklärung für einen LCP, der trotz optimierter Bilder nicht sinkt. Das Dateiformat zu wechseln bringt nichts, solange der Browser das HTML, das die Datei erwähnt, noch gar nicht hat.

Zum INP ist die Beziehung mittelbar, aber real: Ein langsamer Server geht oft mit viel JavaScript einher, das im Browser ausgleicht, was auf dem Server nicht gelöst wurde, und das belegt den Hauptthread genau dann, wenn der Nutzer zu interagieren beginnt.

Für eine Prüfung im technischen SEO folgt daraus eine Reihenfolge: den TTFB vor allem anderen ansehen. Er ist die einzige Kennzahl dieser Familie, deren Verbesserung die übrigen automatisch mitzieht.

Dieselbe Beziehung erklärt, warum der TTFB in Diskussionen über das Crawl-Budget auftaucht. Jede Seite, die der Crawler anfordert, kostet Serverzeit, und ein hoher TTFB senkt, wie viele Seiten er in einer Sitzung schafft. Auf einer Website mit tausenden URLs entscheidet das, was wochenlang nicht indexiert wird.

Dazu kommt eine Wirkung zweiter Ordnung, die selten erwähnt wird: Ein langsamer Server verleitet dazu, im Browser auszugleichen. Man ergänzt JavaScript, damit die Seite schnell „wirkt“, und dieser Code konkurriert am Ende genau dann um den Hauptthread, wenn der Nutzer interagieren will — was den INP verschlechtert. Serverträgheit zahlt man zweimal.

• Den TTFB für „die Zeit des Servers“ halten und den Hoster wechseln, obwohl das Problem eine Weiterleitungskette war.
• Aus dem Büro messen und daraus schließen, es sei gut: Die Entfernung zum Server verändert das Ergebnis stärker als fast jede Optimierung.
• Einen Zwischenspeicher einschalten und nicht prüfen, ob er auf den Seiten greift, die den Traffic bekommen — meist sind das die mit Parametern.
• Bilder optimieren, um den LCP zu senken, ohne vorher den TTFB anzusehen, der ihn mitzieht.
• Alte interne Weiterleitungen stehen lassen, weil sie „funktionieren“: Sie funktionieren für den Nutzer und kosten bei jedem Besuch und jedem Crawl.