TTFB und die Serverantwort.

TTFB ist die Zeit zwischen dem Absenden der Anfrage durch den Browser und dem Empfang des ersten Bytes vom Server — der Boden, auf dem alle anderen Metriken stehen.

Die Zeit bis zum ersten Byte ist keine Core-Web-Vitals-Metrik, beeinflusst aber alle drei direkt. Der Grund ist einfach: Bis der Server antwortet, kann der Browser nichts tun. Eine Sekunde bis zum ersten Byte holt auch die bestoptimierte Seite nicht zurück. Deshalb liegt hier der Boden der Performance-Arbeit.

Google nennt unter 800 Millisekunden als gutes Ziel. Der vom Live-Server gemessene Wert dieser Website: 0,302 Sekunden; auch die drei betreuten Projekte messen unter 300 Millisekunden. Die Zahlen sind das Ergebnis einer Hosting-Entscheidung, nicht einer Optimierungsanstrengung.

Wohin die Zeit geht

Die Zeit bis zum ersten Byte ist keine einzelne Operation, sondern eine Kette. Die Kette zu zerlegen zeigt, welches Glied lang ist, und jedes Glied hat seine eigene Behandlung.

1. Weiterleitungen — wurde die Anfrage an eine andere Adresse geschickt, beginnt die Kette von vorn. Jeder Sprung ist ein voller Umlauf.
2. Namensauflösung — wird die Adresse erstmals aufgelöst, kostet das eine Abfrage.
3. Verbindungsaufbau — der TCP-Handschlag und die Aushandlung der sicheren Verbindung.
4. Anfrageübertragung — die physische Distanz vom Nutzer zum Server. Die Lichtgeschwindigkeit setzt eine Untergrenze.
5. Serverarbeit — wird die Seite erzeugt, eine Datenbank abgefragt, oder kommt sie aus dem Cache?
6. Antwortübertragung — das erste Byte erreicht den Nutzer.

Der vierte und sechste Punkt sind physisch: Die Distanz zwischen Nutzer und Server lässt sich nicht verkürzen, aber der Server lässt sich dem Nutzer nähern. Das ist die einzige Aufgabe der Content-Delivery-Netze, und für statische Inhalte ist die Wirkung dramatisch.

Der fünfte Punkt ist die Softwareseite, und dort lebt die größte Varianz. Zwischen einem System, das bei jeder Anfrage die Datenbank abfragt und die Seite erzeugt, und einem, das eine vorab erzeugte Datei sendet, liegt eine Größenordnung.

Die Weiterleitungskette: die stillen Kosten

Der erste Punkt wird am meisten übersehen. Tippt ein Nutzer die Adresse unvollständig oder klickt einen alten Link, wird die Anfrage weitergeleitet und die Kette beginnt von vorn. Eine Kette mit zwei Sprüngen verdoppelt die Zeit bis zum ersten Byte leicht.

Die typische Kette: Der Nutzer kommt über das unsichere Protokoll und ohne Subdomain, wird zuerst aufs sichere Protokoll geleitet, dann auf die bevorzugte Subdomain. Zwei Sprünge, zwei volle Umläufe.

Die Lösung: die Weiterleitung in der frühestmöglichen Schicht und in einem Sprung. Eine auf Edge-Server-Ebene definierte Regel ist schneller als eine Weiterleitung in der Anwendungsschicht — und ihre Serverkosten sind null.

Auf dieser Website wurde diese Regel gemessen und dokumentiert: Die Weiterleitung von der Apex-Adresse auf www funktioniert, aber nicht in der idealen Schicht — sie lebt in der Anwendungsschicht. Die gemessenen Kosten blieben im Netzrauschen (zwanzig Anfragen, ohne Cache, live: Basis ~186 Millisekunden, mit Weiterleitung ~195), also nicht dringend. Aber die richtige Schicht ist bekannt und notiert.

Liegt der gemessene Unterschied im Netzrauschen, ist er kein dringendes Problem — aber eine Schuld, die man kennen muss.

Statische Dateien ausliefern

Der sicherste Weg, die Serverarbeit auf null zu bringen: die Seite nicht im Anfragemoment erzeugen. Eine vorab erzeugte Datei zu senden ist um eine Größenordnung billiger als Datenbankabfrage und Template-Verarbeitung — und weil das Ergebnis für jeden Nutzer gleich ist, lässt es sich auf Edge-Servern unbegrenzt cachen.

Auf dieser Website werden sämtliche Seiten zur Bauzeit erzeugt und als statische Dateien ausgeliefert. Achtundfünfzig Seiten, zusammen 1.059 Kilobyte. Das einzige zur Anfragezeit laufende Stück Code ist der serverseitige Vermittler des Kontaktformulars — alles andere ist eine Datei.

Die Entscheidung ist ebenso eine Verlässlichkeits- wie eine Performance-Entscheidung: Wo kein Code läuft, stürzt kein Code ab. Es gibt keine Anwendungsschicht, die bei wachsendem Verkehr skalieren müsste.

Auch die Grenze dieses Ansatzes ist klar: Systeme mit wirklich personalisierten Inhalten, Sitzungsverwaltung und sich schnell ändernden Daten können nicht statisch sein. Aber die große Mehrheit der Präsentationsseiten, Dokumentationen, Blogs und Vitrinen kann es — und ist es meist nicht.

Die Cache-Schichten

Das stärkste Werkzeug gegen die Zeit bis zum ersten Byte ist der Cache, und er arbeitet in mehreren Schichten. Die äußerste ist der eigene Browser des Nutzers: Eine früher geladene Ressource wird gar nicht erst angefragt, die Zeit wird null. Die nächste sind die Edge-Server: Die Ressource kommt von einem geografisch nahen Server, die Distanz schrumpft.

Die innerste Schicht ist der eigene Cache des Servers: Eine erzeugte Seite wird gespeichert und bei späteren Anfragen nicht neu erzeugt. Auf statischen Websites ist diese Schicht unnötig, denn die Seite liegt ohnehin erzeugt bereit.

Damit die Schichten funktionieren, müssen die Cache-Header richtig geschrieben sein, und die Grundspannung lautet: Ein langer Cache ist schnell, aber Aktualisierungen verbreiten sich nicht. Die Lösung ist ein aus dem Inhalt abgeleiteter Versionsstempel — ändert sich die Datei, ändert sich ihre Adresse; wenn nicht, bleibt sie gleich. Auf dieser Website tragen die Stil- und Skriptlinks diesen Stempel, und die Cache-Dauer ist auf ein Jahr gesetzt.

Protokoll und Verbindung

Der Verbindungsaufbau ist der Fixkostenanteil der Zeit bis zum ersten Byte, und die Protokollversion beeinflusst ihn direkt. Moderne Protokolle verringern die Handschlagrunden und erlauben mehrere Anfragen über eine einzige Verbindung; die Kosten, je Ressource eine neue Verbindung zu öffnen, entfallen.

Das hat einen Teil der klassischen Optimierungsratschläge entwertet. Dateien in ein Paket zu bündeln zählte auf alten Protokollen, weil jede Anfrage teuer war; auf modernen können mehrere kleine Dateien besser sein als eine große — denn die unveränderten Teile bleiben im Cache.

Auf den drei von dieser Website betreuten Projekten wurde die neueste Protokollversion durch Messung bestätigt, und die Zeiten bis zum ersten Byte liegen unter 300 Millisekunden. Die Protokollwahl ist meist die Entscheidung des Hosting-Anbieters, und zu tun bleibt nur, die Unterstützung sicherzustellen — doch ihre Wirkung übertrifft die meisten Code-Optimierungen.

Eine letzte Messnotiz: Die Zeit bis zum ersten Byte ist keine einzelne Zahl, sondern eine Verteilung, und sie variiert dramatisch mit der Geografie. Eine Messung von einem Ort nahe Ihrem Server zeigt nicht, was ferne Nutzer erleben. Ein aussagekräftiges Bild braucht Messungen aus mehreren Regionen — und zu wissen, wo Ihr Publikum wirklich ist, bestimmt, welche Regionen zählen. Für eine Website, die die Türkei bedient, kann die Messung über Europa täuschen; ein lokaler Messpunkt gibt eine ehrlichere Zahl.