Time To First Byte (TTFB)

Was TTFB tatsächlich misst

Time To First Byte ist die Zeitspanne zwischen dem Moment, in dem der Browser eine Navigation startet, und dem Moment, in dem das erste Byte der Antwort eintrifft. In der Navigation Timing API entspricht das responseStart minus startTime. Der Wert klingt nach Serverleistung, enthält aber deutlich mehr: DNS-Auflösung, TCP-Verbindungsaufbau, TLS-Handshake, jede Weiterleitung auf dem Weg und erst danach die eigentliche Verarbeitung der Anfrage auf dem Server.

Diese Zusammensetzung ist der Grund, warum TTFB so oft falsch gelesen wird. Ein Wert von 1,4 Sekunden sagt für sich genommen nichts darüber aus, ob die Datenbank langsam ist, ob PHP ohne Opcode-Cache läuft, ob eine 301-Kette zwei zusätzliche Roundtrips kostet oder ob der Nutzer schlicht 8.000 Kilometer vom Origin entfernt sitzt. TTFB ist ein Summenwert, und Summenwerte lassen sich nur zerlegen, nie direkt optimieren.

Die Chrome-Dokumentation zum Chrome UX Report ordnet TTFB ausdrücklich als experimentelle beziehungsweise diagnostische Metrik ein, nicht als eine der drei Kennzahlen, über die die Bewertung der wichtigsten Nutzererfahrungs-Signale entschieden wird. Die offizielle Google-Search-Dokumentation nennt weiterhin nur LCP, INP und CLS mit den Zielwerten 2,5 Sekunden, unter 200 Millisekunden und 0,1. Wer TTFB als vierten Core Web Vital verkauft, verkauft eine Erfindung.

Trotzdem ist die Metrik nicht folgenlos. Jede Millisekunde vor dem ersten Byte ist eine Millisekunde, in der der Browser nichts tun kann: kein Parsen, kein Preload-Scanner, kein Bildabruf. TTFB ist die Untergrenze für alles, was danach kommt. Ein Origin, der 1,5 Sekunden für das erste Byte braucht, wird bei sonst perfekter Frontend-Arbeit kaum unter 2,5 Sekunden LCP landen. Genau in dieser Rolle, als Deckel für alle nachgelagerten Metriken, gehört der Wert in jedes technische Audit.

TTFB messen, ohne sich selbst zu belügen

Der schnellste Zugang bleibt der Network-Tab der Chrome DevTools. Dokument-Request auswählen, im Timing-Panel auf die Zeile für die Wartezeit auf die Serverantwort schauen, fertig. Dasselbe funktioniert für jede einzelne Ressource, was bei API-Aufrufen oder externen Skripten oft aufschlussreicher ist als der Wert des HTML-Dokuments. Der große Nachteil: das ist eine einzelne Messung, von einem Standort, mit einem Verbindungstyp, mit dem Cache-Zustand des Testrechners. Als Beweis taugt sie nicht, als Hypothesengenerator sehr wohl.

Für belastbare Werte braucht es zwei Ebenen. Im Labor liefern WebPageTest und GTmetrix reproduzierbare Läufe mit definiertem Standort und definierter Verbindung, wobei der erste Lauf ohne Cache und der zweite mit Cache getrennt zu betrachten sind. Im Feld liefert CrUX die Verteilung echter Nutzer, und nur die zählt am Ende. DebugBear hat 2025 zusätzlich einen globalen TTFB-Test eingeführt, mit dem sich Antwortzeiten über mehrere Standorte vergleichen und Cache-Treffer eines CDN erkennen lassen. Für internationale Projekte ist das der relevante Blickwinkel: ein Test vom Origin-Standort aus versteckt genau die Latenz, die der Zielmarkt erlebt.

Zwei Fallstricke der Felddaten muss man kennen. Erstens erhebt CrUX TTFB laut Chrome-Dokumentation nur bei vollständigen Seitenaufrufen, während LCP zusätzlich bei Back-Forward-Cache-Navigationen und vorgerenderten Seiten erfasst werden kann. Die Stichproben sind also unterschiedlich groß, und ein direkter Vergleich der Verteilungen führt in die Irre. Zweitens enthält der CrUX-TTFB Verbindungsaufbau und Weiterleitungen und kann Antworten aus einem Browser-Cache, einem CDN oder einer bereits offenen Verbindung widerspiegeln. Geografie, Cache-Zustand und Methodik entscheiden über das Ergebnis, bevor der Server überhaupt beteiligt ist.

Dazu kommt ein Bruch in der Zeitreihe. Chrome hat im Februar 2025 sein Verhalten bei responseStart an Firefox und Safari angeglichen, die bereits Daten aus Early-Hints-Antworten mitzählten. Seitdem können Seiten mit HTTP 103 Early Hints einen deutlich besseren gemeldeten TTFB ausweisen, wie DebugBear in seinem Jahresrückblick 2025 dokumentiert hat. Das erste Byte kommt dann tatsächlich früher, das fertige HTML aber nicht. Wer Quartalsvergleiche über diesen Zeitpunkt hinweg zieht, vergleicht zwei Definitionen. Seit Februar 2025 weist CrUX außerdem die LCP-Teilkomponenten aus, darunter die Server-Antwortzeit: das ist der sauberere Weg, den Serveranteil an LCP zu belegen, statt TTFB als Ersatzgröße zu behandeln.

Welcher Wert wirklich gut ist

Die Referenz, die in der Praxis trägt, kommt aus dem Web Almanac 2025 von HTTP Archive: unter 0,8 Sekunden gilt als gut, 0,8 bis 1,8 Sekunden als verbesserungswürdig, über 1,8 Sekunden als schlecht. Gemessen wird am 75. Perzentil der echten Nutzer, nicht am Durchschnitt und schon gar nicht am besten Lauf. Das sind Diagnosebänder, keine Ranking-Grenzen. Die kursierende Behauptung, Google habe eine Ranking-Schwelle bei 600 Millisekunden eingeführt, findet in keiner veröffentlichten Google-Dokumentation eine Grundlage.

Interessanter als die Grenzwerte ist, wie weit das Web davon entfernt ist. Die Almanac-Auswertung auf Basis von HTTP-Archive- und CrUX-Daten aus Juli 2025 zeigt auf dem Desktop 55 Prozent der Seiten im guten Bereich gegenüber 54 Prozent im Vorjahr, auf Mobilgeräten 44 Prozent gegenüber 42 Prozent. Ein Punkt Verbesserung auf dem Desktop, zwei auf mobil, in einem Jahr. Anders formuliert: 56 Prozent der Seiten erreichen mobil keinen guten TTFB. Zum Vergleich lag die Bestehensquote der Core Web Vitals insgesamt im selben Bericht bei 56 Prozent auf dem Desktop und 48 Prozent auf mobil, was zeigt, wie wenig TTFB allein über die Gesamtbewertung aussagt.

Meine Position dazu ist unbequem: TTFB ist die am stärksten überbewertete Kennzahl in technischen SEO-Berichten. Sie ist leicht zu messen, leicht zu visualisieren und schwer zu deuten, also landet sie prominent im Report, während der eigentliche Engpass im Render-Delay oder in der Ressourcenladeverzögerung steckt. Auch die bestätigten Google-Updates des Jahres 2025, vom Core Update im März über das Juni-Update und das Spam Update im August bis zum Dezember-Update vom 11. bis 29. Dezember mit rund 18 Tagen Ausrollzeit, waren keine Geschwindigkeits-Updates. Google beschrieb das Dezember-Update laut Search Engine Land als reguläres Update mit Fokus auf relevante, zufriedenstellende Inhalte. Wer nach einem breiten Kernalgorithmus-Update Sichtbarkeit verliert und dann am Server schraubt, behandelt das falsche Problem.

Wo TTFB in einer Netlinking-Operation zählt

Für den Wert eines Backlinks spielt der TTFB der verweisenden Domain keine belegbare Rolle. Weder Googles Dokumentation noch die Update-Berichterstattung der letzten zwölf Monate stützen die These, dass ein langsamer Server die weitergegebene Autorität mindert. Thema, Autorität, Crawlbarkeit der Platzierung und Qualität der Zielseite sind getrennte Größen. Wer einen Linkkauf mit dem TTFB des Publishers begründet oder ablehnt, argumentiert an der Mechanik vorbei.

Operativ gibt es trotzdem drei Stellen, an denen die Metrik zählt. Erstens das Crawling: ein Origin, der unter Last dreistellige Antwortzeiten in den Sekundenbereich schiebt, bekommt weniger Abrufe pro Tag, und frisch platzierte Links werden entsprechend später gesehen. Auf einem Netzwerk mit hoher Publikationsfrequenz ist das kein Detail. Zweitens die Zielseite: wenn eine Kampagne Autorität auf eine Kategorieseite schickt, die 1,9 Sekunden für das erste Byte braucht, verschenkt man einen Teil der Wirkung an der Konversionsseite, nicht am Link. Drittens die Bewertung der Hosts: eine dauerhaft träge Seite ist selten ein gepflegtes Medium, und das ist ein Qualitätsindiz, kein Ranking-Argument.

Bei den französischen Redaktionsmedien, die wir im Eigenbetrieb führen, ist der Serveranteil deshalb Teil der Betriebsroutine und nicht Teil des Verkaufsarguments: statische Auslieferung über ein CDN, keine Datenbankabfrage im kritischen Pfad, gleiche Infrastrukturbasis für alle Titel. Wer prüfen will, wie ein Medium technisch dasteht, bevor er dort veröffentlicht, kann jedes Medium samt Kennzahlen ohne Anmeldung durchsehen und die Werte selbst nachmessen. Was eine Platzierung dort kostet, steht ebenfalls offen, ohne versteckte Provision, in der öffentlichen Preisübersicht.

Was in Audits regelmäßig schiefgeht

Der häufigste Fehler ist die Einzelmessung als Befund. Ein DevTools-Wert vom Büro-WLAN aus, ein Screenshot, eine Empfehlung. Aus eigener Audit-Erfahrung weicht dieser Wert regelmäßig um mehrere hundert Millisekunden vom 75. Perzentil der echten Nutzer ab, in beide Richtungen. Der zweite Fehler ist die verdeckte CDN-Messung: der Test läuft an einem Standort mit warmem Cache, meldet 120 Millisekunden und verschweigt, dass der Cold-Cache-Pfad zum Origin viermal so lange braucht. Wer international arbeitet, misst aus dem Zielmarkt, mit und ohne Cache-Treffer.

Dritter Klassiker: Weiterleitungen. Eine Kette aus mehreren aufeinanderfolgenden Umleitungen addiert vollständige Roundtrips zum gemessenen TTFB, und keine Server-Optimierung der Welt holt das zurück. Erst die Kette auflösen, dann den Server anfassen. Vierter Klassiker seit 2025: Early Hints als Kosmetik. Der gemeldete Wert fällt, der Nutzer sieht keine Sekunde früher etwas, das Reporting sieht gut aus. Early Hints sind sinnvoll, wenn sie kritische Ressourcen vorziehen, nicht wenn sie eine Kennzahl schönen.

Auf der Serverseite ist die Reihenfolge der Untersuchung fast immer dieselbe. Zuerst prüfen, ob überhaupt dynamisch gerendert wird oder ob eine Seite ohne Personalisierung sinnlos bei jedem Aufruf neu gebaut wird, was oft direkt in die Frage nach serverseitigem Rendering versus statischer Auslieferung mündet. Dann der Opcode-Cache: eine PHP-Installation ohne aktiviertes OPcache verbrennt bei jedem Request Kompilierzeit. Danach die Datenbank, wo in der Regel zwei oder drei Abfragen ohne passenden Index den Großteil der Verarbeitungszeit ausmachen. Erst ganz am Ende kommen Feinheiten der Apache- oder Nginx-Konfiguration, Keep-Alive-Einstellungen und Worker-Zahlen, die selten mehr als zweistellige Millisekundenbeträge bewegen.

Und schließlich der Fehler, der am meisten Zeit kostet: TTFB isoliert zu optimieren, ohne LCP mitzumessen. Der Serveranteil sinkt von 900 auf 400 Millisekunden, LCP bleibt bei 3,1 Sekunden, weil der Engpass im Render-Delay eines blockierenden Skripts liegt. Seit CrUX die LCP-Teilkomponenten ausweist, lässt sich diese Frage in wenigen Minuten beantworten, statt sie zu raten. Wer den Serveranteil belegt hat, darf ihn optimieren. Wer ihn nur vermutet, optimiert Statistik.