TTFB.

TTFB ist die Zeit zwischen dem Absenden der Anfrage durch den Browser und dem Empfang des ersten Bytes vom Server.

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.

1. Die Weiterleitungskette auf einen Sprung verkürzen — jeder Sprung ist ein voller Hin- und Rückweg.
2. Statische Dateien ausliefern — der sicherste Weg, die Serverarbeit auf null zu bringen.
3. Einen Edge-Cache nutzen — den Server näher an die Nutzerin bringen.
4. Das moderne Protokoll bestätigen — es verringert die Handshake-Runden.
5. 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.