Was ist TTFB (Time to First Byte)?

Es ist keine Core-Web-Vitals-Metrik, wirkt aber auf alle drei unmittelbar: Solange der Server nicht antwortet, kann der Browser nichts tun. Damit ist hier das Fundament der Leistungsarbeit.

Google nennt als guten Zielwert weniger als 800 Millisekunden. Die Livemessung dieser Website beträgt 0,302 Sekunden; auch in den drei betreuten Projekten liegt der Wert unter 300 Millisekunden.

Die Dauer ist eine Kette: Weiterleitung, Namensauflösung, Verbindungsaufbau, Absenden der Anfrage, Serverarbeit und Senden der Antwort. Jedes Glied hat seine eigene Behandlung.

Das am häufigsten übersehene Glied ist die Weiterleitung. Eine Kette mit zwei Sprüngen verdoppelt die Zeit leicht; weitergeleitet werden sollte auf der frühestmöglichen Ebene und in einem einzigen Sprung.

Der sicherste Weg, die Serverarbeit auf null zu bringen, ist, die Seite nicht zur Anfragezeit zu erzeugen. Eine bereits erzeugte Datei zu senden ist um Größenordnungen günstiger als eine Datenbankabfrage und lässt sich auf Edge-Servern unbegrenzt zwischenspeichern.

Cache-Ebenen sind das stärkste Mittel zur Senkung der Zeit: der Browser-Cache, Edge-Server und der Cache des Servers selbst. Bei statischen Websites ist die dritte Ebene entbehrlich, denn die Seite liegt bereits erzeugt vor.

Auch die Protokollversion wirkt unmittelbar: Moderne Protokolle verringern die Handshake-Runden und erlauben mehrere Anfragen über eine Verbindung. Das hat den klassischen Rat, Dateien zusammenzufassen, teilweise überholt.

Beim Messen zählt die Geografie: Eine Messung nahe am Server zeigt nicht, was entfernte Nutzende erleben. Für ein aussagekräftiges Bild braucht es Messungen aus mehreren Regionen.

• Die Weiterleitungskette auf einen Sprung verkürzen — jeder Sprung ist ein voller Hin- und Rückweg.
• Statische Dateien ausliefern — der sicherste Weg, die Serverarbeit auf null zu bringen.
• Einen Edge-Cache nutzen — den Server näher an die Nutzerin bringen.
• Das moderne Protokoll bestätigen — es verringert die Handshake-Runden.
• Aus mehreren Regionen messen — eine einzige Messstelle führt in die Irre.

Auf dieser Website beträgt die Livemessung 0,302 Sekunden, und auch in den drei betreuten Projekten liegt der Wert unter 300 Millisekunden; die Zahlen sind das Ergebnis einer Hosting- und Architekturentscheidung, nicht einer Optimierungsanstrengung.

Eine Erinnerung: Diese Dauer entspricht nichts, was die Nutzerin sieht — der Bildschirm ist noch leer. Doch alles Weitere setzt darauf auf, und so schlägt jede Hundertstelsekunde hier unmittelbar auf LCP durch.

So wird sie gemessen

Es gibt drei Wege, und jeder sagt etwas anderes. Die Entwicklertools des Browsers zeigen einen einzelnen Ladevorgang, die Kommandozeile die rohe Serverantwort und Felddaten das, was echte Nutzer erleben. Entschieden wird nach Felddaten; die anderen beiden helfen, die Ursache zu finden.

1. Chrome DevTools → Network → Anfrage → Timing → „Waiting for server response“
2. curl -o /dev/null -s -w '%{time_starttransfer}\n' https://www.beispiel.de/
3. PageSpeed Insights → Felddaten → Time to First Byte (75. Perzentil)

Die Schwellenwerte sind auf web.dev definiert: 800 Millisekunden oder weniger gelten als gut, mehr als 1.800 Millisekunden als schlecht, dazwischen besteht Verbesserungsbedarf. Der Wert sollte bei 75 Prozent der Besuche unter der Schwelle bleiben.

Häufige Fehler

• Nach einer einzigen Messung entscheiden — die erste Anfrage kommt vor dem Aufwärmen der Caches und kann bei Wiederholung deutlich sinken; maßgeblich ist der Median mehrerer Läufe.
• Nur in Servernähe messen — ein Server in Istanbul wirkt aus Istanbul schnell, aus Frankfurt anders.
• Weiterleitungen übersehen — jeder Sprung von http zu https oder von der Domain ohne www zur www-Adresse addiert sich; messen Sie mit der Adresse, die Nutzer eingeben.

Wenn Sie die Geschwindigkeit Ihrer eigenen Website verbessern möchten: Unser individuelles Webdesign liefert Performance als messbares Budget aus — Ziel ist ein LCP unter 0,8 Sekunden.