Serverantwortzeit reduzieren: TTFB messen und gezielt verbessern

Reduzieren Sie die Serverantwortzeit, indem Sie messen, wo eine Anfrage wartet, und anschließend diesen Abschnitt verbessern. Ein spätes erstes Byte kann durch Weiterleitungen, Verbindungsaufbau, einen entfernten Ursprung, Anwendungsarbeit, Datenbankabfragen oder einen Cache-Miss entstehen. Wer diese Ursachen vor einem Hostingwechsel nicht trennt, verlagert möglicherweise denselben Engpass auf einen teureren Server.

Time to First Byte, kurz TTFB, bezeichnet die Zeit bis zum ersten Antwortbyte einer Navigation im Browser. Sie umfasst mehr als die HTML-Erzeugung Ihrer Anwendung. Das praktische Ziel ist früher nutzbarer Inhalt. Prüfen Sie deshalb neben dem ersten Byte immer die Auswirkung auf die Darstellung.

Definieren Sie die Messung vor dem Zielwert

Googles Empfehlungen zur TTFB-Optimierung nennen höchstens 800 Millisekunden als groben guten Richtwert. TTFB gehört selbst nicht zu den drei Core Web Vitals. Höhere Werte verdienen eine Untersuchung, doch für das abschließende Urteil zählt auch, wann sinnvoller Inhalt erscheint.

Eine serverseitig gerenderte Seite kann länger an HTML arbeiten und trotzdem früher hilfreiche Inhalte zeigen als eine clientseitige Seite, die sofort eine leere Hülle liefert. Langsame Anwendungsarbeit wird dadurch nicht wünschenswert. Eine Verbesserung des ersten Bytes durch Verschieben sämtlicher nützlicher Arbeit auf JavaScript kann aber ein schlechter Tausch sein.

Messungen haben außerdem unterschiedliche Grenzen. TTFB einer Navigation im Feld kann Verzögerungen enthalten, die eine Laborprüfung des endgültigen Dokuments ausschließt. Die frühere Lighthouse-Prüfung der Serverantwortzeit bildete nicht die gesamte DNS-, Weiterleitungs- und Verbindungsfolge ab. Aktuelle Chrome-Dokumentation verwendet auch den Hinweis Document request latency. Alte Anleitungen können daher andere Bezeichnungen als Ihr Bericht enthalten.

Notieren Sie, was Sie optimieren: Feld-TTFB einer Navigation, Wartezeit einer Browseranfrage, einen Anwendungstimer oder ein Kommandozeilenergebnis. Werden diese Werte gleichgesetzt, entstehen widersprüchliche Schlussfolgerungen, selbst wenn jede einzelne Messung stimmt.

Verfolgen Sie die Anfrage bis zum nutzbaren HTML

Vor der ersten brauchbaren Dokumentantwort können mehrere Schritte liegen. Deren Aufwand hängt von DNS-Caches, vorhandenen Verbindungen, Weiterleitungen, Protokollen und dem Weg durch Ihre Infrastruktur ab.

Nicht jeder Abschnitt tritt bei jeder Anfrage auf. Wiederkehrende Besucher können Verbindungen wiederverwenden. Ein Cache-Treffer kann die Anwendungsausführung vermeiden. Eine private Kontoseite darf kein öffentliches HTML für eine andere Person wiederverwenden.

Besonders aufschlussreich ist oft der Vergleich zweier legitimer Wege zum selben Inhalt. Eine bereits zwischengespeicherte öffentliche Seite und eine ungecachte Seite können stark unterschiedliche Zeiten haben. Die Differenz zeigt, welcher Systemteil Besucher derzeit vor langsamer Ursprungsarbeit schützt.

Messen Sie den tatsächlichen Besucherweg im Browser

Öffnen Sie DevTools vor der Navigation und prüfen Sie im Network-Bereich die Dokumentanfrage. Notieren Sie endgültige URL, Status, Protokoll, Antwortheader und Zeitabschnitte. Lassen Sie Weiterleitungen sichtbar. Ein Test direkt am endgültigen Ziel erklärt keine Verzögerung durch eine vorgeschaltete Kampagnenweiterleitung oder einen veralteten internen Link.

Führen Sie kalte und warme Tests getrennt durch. Das Abschalten des Browsercaches beeinflusst dessen Wiederverwendung, umgeht aber nicht zwingend CDN oder serverseitigen Seitencache. Auch ein privates Browserfenster garantiert keinen leeren Edge-Cache. Benennen Sie die Ebene, die Sie kontrollieren wollen.

Testen Sie repräsentative Inhalte. Die beliebte Startseite kann fast immer gecacht sein, während ältere Artikel bei Bedarf erzeugt werden. Suche, Konto und Kasse können andere Wege nehmen als öffentliche Inhalte. Behandeln Sie angemeldete Tests vertraulich und übernehmen Sie keine Sitzungscookies in gemeinsame Berichte.

Wiederholen Sie Tests aus wichtigen Besucherregionen, sofern Sie dafür einen geeigneten Testdienst oder ein Monitoring besitzen. Eine schnelle Anfrage nahe am Ursprung sagt wenig über weit entfernte Besucher aus. Beschreiben Sie Ort und Bedingungen, statt einen Einzelwert als weltweites Ergebnis auszugeben.

Trennen Sie mit curl kumulative Zeitmarken

Dieser Befehl führt eine GET-Anfrage aus, verwirft den Inhalt und gibt kumulative Zeitmarken aus. Ersetzen Sie die Beispieladresse durch eine öffentliche Seite, die Sie testen dürfen. Weiterleitungen werden absichtlich nicht verfolgt, damit sie sichtbar bleiben.

curl --silent --show-error --output /dev/null \
  --write-out 'status=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://example.com/'

Die Werte sind seit Übertragungsbeginn vergangene Zeiten. Addieren Sie sie nicht. Bei einer einfachen neuen HTTPS-Verbindung können Differenzen benachbarter Marken Verbindung und TLS näher eingrenzen. Proxys, Wiederverwendung und Protokollverhalten verändern jedoch unter Umständen die Bedeutung.

Die Zeit zwischen Verbindungsaufbau und erstem Byte ist kein reiner Anwendungstimer. Sie enthält Netzwerkeffekte und Serverarbeit. Grenzen Sie damit den wahrscheinlichen Problembereich ein und unterscheiden Sie anschließend mit Serverinstrumentierung Datenbank, Rendering und Warteschlangen.

Prüfen Sie zuerst den Status. Eine schnelle Weiterleitung, Fehlerseite oder Botprüfung ist keine schnell ausgelieferte erfolgreiche Seite. Ersetzen Sie GET auch nicht der Einfachheit halber durch HEAD, wenn Ihre Anwendung beide Methoden anders behandeln könnte.

Speichern Sie mehrere vergleichbare Ergebnisse mit Datum und Veröffentlichungsversion. Ein Median erleichtert den Vergleich kleiner Reihen, doch bewahren Sie Einzelwerte und ungewöhnliche Fehler auf. Ein zentraler Wert kann sporadisch langsame Anfragen verdecken, die Besucher tatsächlich bemerken.

Instrumentieren Sie die Anwendung ohne private Details

Servertraces können Arbeit trennen, die Browserzeiten zusammenfassen. Untersuchen Sie Datenbankabfragen, Vorlagenrendering, externe Anfragen, Cachezugriffe, Workerwarteschlangen und Dateizugriffe. Verwenden Sie über Versionen hinweg einheitliche Abschnittsnamen, damit Änderungen vergleichbar bleiben.

Der Antwortheader Server-Timing stellt benannte Laufzeiten für Browserwerkzeuge bereit. Dieses vollständige PHP-Beispiel misst die Erzeugung einer kleinen öffentlichen HTML-Antwort. Es verwendet hrtime, verfügbar ab PHP 7.3. Produktivsysteme sollten eine aktuell unterstützte, kompatible Laufzeit verwenden.

<?php
declare(strict_types=1);

$started = hrtime(true);
$title = htmlspecialchars('Performance example', ENT_QUOTES, 'UTF-8');
$html = '<!doctype html><html lang="en"><meta charset="utf-8">'
      . '<title>' . $title . '</title><h1>' . $title . '</h1></html>';
$durationMs = (hrtime(true) - $started) / 1e6;

header('Content-Type: text/html; charset=utf-8');
header('Cache-Control: no-store');
header('Server-Timing: render;dur=' . number_format($durationMs, 3, '.', ''));
echo $html;

Die Dauer wird erst bei der Ausführung gemessen; das Beispiel behauptet keinen Benchmark. Seine no-store-Richtlinie hält diese Diagnoseantwort aus HTTP-Caches fern. Sie ist keine Empfehlung für sämtliche öffentlichen Seiten.

Messen Sie tatsächliche Operationen, statt die gesamte Anfrage als Datenbankzeit zu bezeichnen. Parallele Vorgänge können sich überlappen, weshalb ihre Laufzeiten nicht zwingend die Gesamtantwortzeit ergeben. Das Warten auf einen freien Worker kann außerdem vor Beginn des Anwendungstimers stattfinden.

Verwenden Sie allgemeine Namen wie render oder database. Veröffentlichen Sie in Headern weder SQL-Anweisungen noch Zugangstokens, Kundenkennungen, interne Hostnamen oder sensible Geschäftsdaten. Detaillierte Traces gehören in angemessen geschützte Monitoringsysteme.

Wählen Sie den Cache passend zur teuren Arbeit

Seiten-, Objekt- und Opcode-Caches lösen unterschiedliche Probleme. Sie können gleichzeitig bestehen. Eine aktivierte Ebene beweist aber nicht, dass die anderen vorhanden oder wirksam sind.

Liefert eine Publikation denselben Artikel an anonyme Besucher, ist vollständiges Seitencaching oft ein sinnvoller Einstieg. Prüfen Sie die Invalidierung nach einer redaktionellen Änderung. Ein schnell gelieferter veralteter Artikel nach einer Korrektur bleibt ein Veröffentlichungsfehler, selbst bei hervorragendem Leistungsbericht.

Bei dynamischen Seiten kann ein Objektcache wiederholte Datenarbeit reduzieren, während die Anwendung weiterhin eine personalisierte Antwort erzeugt. Der standardmäßige WordPress-Objektcache ist nicht automatisch über Anfragen hinweg persistent. Ein persistentes Backend benötigt eine passende Implementierung. Der Nutzen hängt davon ab, was die Anwendung tatsächlich speichert.

PHP OPcache vermeidet erneute Kompilierung, aber keine langsamen Abfragen oder entfernten Netzwerkaufrufe. Prüfen Sie Konfiguration und Laufzeitkompatibilität, ohne eine Reparatur ineffizienter Architektur zu erwarten. Fragen Sie bei verwalteten Plattformen zuerst nach den vom Anbieter kontrollierten Ebenen.

Browsercaching hilft vor allem nach dem ersten Empfang einer Ressource. Es garantiert keinen schnellen Erstbesuch. Der Leitfaden zum Browsercaching erklärt Gültigkeit, Validierung und das Verhindern der Speicherung.

Schützen Sie Sitzungen, Warenkörbe und persönliche Inhalte

Beginnen Sie gemeinsames HTML-Caching mit einer engen Positivliste öffentlicher Seiten. Schließen Sie Konto, Warenkorb, Kasse und andere personalisierte Routen aus, sofern dafür keine bewusst entworfene und geprüfte Strategie besteht. Sitzungscookies und Autorisierung benötigen ausdrückliche Regeln.

Ein Cookie allein garantiert nicht, dass jeder Vermittler eine Antwort als privat behandelt. Lesen und überprüfen Sie das Verhalten von CDN und Anwendungscache. Besondere Vorsicht gilt Regeln, die Caching gegen Antwortheader erzwingen oder Abfrageparameter ohne Kenntnis ihrer Bedeutung ignorieren.

Testen Sie mit zwei getrennten Sitzungen und einem abgemeldeten Browser. Niemand darf Namen, Warenkorb, Preise oder Kontostatus einer anderen Person erhalten. Eine gute Trefferquote ist wertlos, wenn die Antwort dem falschen Besucher gehört.

Halten Sie Cacheschlüssel verständlich. Reine Kampagnenparameter können öffentliche Inhalte unnötig aufteilen. Produktauswahl, Währung, Sprache und Zugriffsstatus können dagegen die Antwort verändern. Normalisieren Sie nur Eingaben, deren Bedeutungslosigkeit für Inhalt und Berechtigung feststeht.

Verbessern Sie den langsamen Ursprung trotz funktionierendem Cache

Cache-Misses bleiben möglich. Neue Inhalte, seltene URLs, Invalidierungen und andere Edge-Standorte können frische Arbeit erfordern. Verbirgt ein Cache einen langsamen Ursprung im üblichen Test, entfällt dadurch nicht dessen Untersuchung.

Nutzen Sie Abfrageprofile, um aufwendige oder wiederholte Datenbankarbeit zu finden. Prüfen Sie Ausführungspläne vor dem Anlegen von Indizes. Ein hilfreicher Leseindex benötigt Speicher und kann Schreibvorgänge beeinflussen. Begründen Sie Änderungen deshalb mit einer gemessenen Abfrage, nicht mit der Annahme, mehr Indizes seien grundsätzlich besser.

Suchen Sie wiederholte Aufrufe in Schleifen, unnötige Datenabrufe und teure Arbeit bei jedem Seitenaufruf. Verschieben Sie Hintergrundaufgaben aus dem kritischen Antwortpfad, soweit die fachliche Korrektheit dies erlaubt. Die Seite sollte nicht auf unabhängige Verwaltungsarbeit warten, nur weil sie im selben Handler steht.

Externe APIs brauchen Zeitlimits, geeignetes Caching und einen Fehlerfallplan. Entscheiden Sie, welche Daten für die erste Antwort wesentlich sind und welche später kommen dürfen. Das Verschieben wichtiger Inhalte beeinflusst Darstellung und Bedienbarkeit. Bewerten Sie die vollständige Nutzeraufgabe statt nur TTFB.

Vergleichen Sie Laufzeit- und Abhängigkeitsversionen vor Aktualisierungen in einer Testumgebung. Unterstützte PHP- oder Node-Versionen gehören zur Wartung, doch Kompatibilität und Leistung müssen mit Ihrer Anwendung geprüft werden. Versprechen Sie keinen pauschalen prozentualen Gewinn durch einen Versionswechsel.

Nutzen Sie ein CDN bei passender Entfernung und Wiederverwendung

Ein CDN kann geeignete Inhalte an einem Edge-Standort nahe dem Besucher ausliefern. Besonders Cache-Treffer vermeiden Fahrten zu einem entfernten Ursprung. Speichert das CDN aber nur statische Ressourcen, kann jede HTML-Anfrage weiterhin vom langsamen Ursprung abhängen.

Prüfen Sie Antwort und dokumentierte Cache-Statusheader des Anbieters. Namen und Bedeutungen unterscheiden sich. Ermitteln Sie Treffer, Miss, Umgehung, Revalidierung oder eine richtliniengemäß veraltete Antwort. Ein CDN-Hostname beweist keinen Treffer.

Messen Sie HTML und statische Ressourcen getrennt. Eine hohe Bildtrefferquote kann neben schlechter HTML-Wiederverwendung bestehen. Beziehen Sie nach Möglichkeit Bytes und Anfragetypen ein. Ein Gesamtprozentsatz kann die eigentlich relevante Trafficart verdecken.

Planen Sie Invalidierung vor längeren Speicherfristen. Veröffentlichung, Korrektur, Berechtigungsänderung und neuer Build brauchen vorhersehbares Verhalten. Unser Leitfaden zu CDN und Edge-Caching erläutert diese Entscheidungen ohne vermeintlich einheitliche Anbietervorgaben.

Betrachten Sie Protokolle als einen Teil der Auslieferung

HTTP/2-Multiplexing und der QUIC-Transport von HTTP/3 können die gemeinsame Verbindungsnutzung verbessern. Der Effekt hängt von Verbindung, Netzwerk und Serverimplementierung ab. Kein Protokoll beseitigt langsame Datenbankarbeit oder garantiert bei jeder Anfrage ein früheres erstes Byte.

Verbindungswiederverwendung und TLS-Sitzungswiederaufnahme können unter passenden Bedingungen erneuten Aufbau reduzieren. Prüfen Sie vorhandene Hosting- und CDN-Funktionen vor Konfigurationsänderungen. Browser zu CDN und CDN zu Ursprung können unterschiedliche Protokolle verwenden.

HTTP 103 Early Hints erlaubt unterstützenden Clients, wichtige Ressourcen vor der endgültigen Antwort anzufordern. Die HTML-Erzeugung wird dadurch nicht sofort fertig. Unterstützung hängt von Browser und Vermittlern ab. Setzen Sie es bei nachgewiesenem Entdeckungsverzug ein und erhalten Sie einen funktionierenden Ablauf ohne Hinweis.

Early Hints verändert möglicherweise auch die Bedeutung einer Erstbyte-Messung. Aktuelles Chrome zählt die Zwischenantwort in responseStart. Das Feld finalResponseHeadersStart bezeichnet, soweit verfügbar, den Beginn der endgültigen Antwortheader. Dokumentieren Sie Browser und Zeitfeld beim Vergleich. Eine frühere Zwischenantwort beweist kein früheres endgültiges HTML.

Komprimierung reduziert vor allem übertragene Bytes. Dynamische Komprimierung verbraucht auch CPU. Prüfen Sie daher ihre Wirkung, statt weniger Ausgabe automatisch mit geringerer Erstbyte-Latenz gleichzusetzen. Die Erklärung zu HTTP/2 und HTTP/3 trennt Transport- und Anwendungsverbesserungen.

Bestimmen Sie, wann Hosting der Engpass ist

Untersuchen Sie Infrastruktur, wenn langsame Antworten mit ausgelasteten Workern, CPU-Sättigung, Speicherdruck, Datenträgerlatenz oder Datenbankkonflikten zusammenfallen. Stoßzeiten sind eine nützliche Spur. Identifizieren Sie trotzdem die begrenzte Ressource vor der Wahl eines größeren Tarifs.

Vergleichen Sie eine einfache statische Antwort mit einer repräsentativen ungecachten Anwendungsantwort bei ähnlichem Auslieferungsweg. Ist nur die Anwendung langsam, untersuchen Sie Abhängigkeiten und Ausführung. Verschlechtern sich beide unter Last, prüfen Sie gemeinsame Ressourcen und den Hostingpfad.

Bei Shared Hosting sind vielleicht nicht alle Metriken zugänglich. Geben Sie dem Anbieter konkrete Belege: Zeitstempel, URLs, Cachezustand, Header und wiederholte Messungen. Fragen Sie, welche Grenzen erreicht wurden und ob der Tarif die nötige Konfiguration erlaubt.

Überprüfen Sie den ursprünglich langsamen Weg erneut

Wiederholen Sie nach einer gezielten Änderung das ursprüngliche langsame Szenario. Prüfen Sie neben Zeiten auch Statuscodes, korrekten Inhalt, Sitzungstrennung, Invalidierung und Fehlerverhalten. Bestätigen Sie anschließend, dass die Verbesserung die Darstellung erreicht und Arbeit nicht nur nach hinten verschiebt.

Nutzen Sie den PageSpeed-Analysator, sofern aktiviert, für öffentliche URLs. Bewahren Sie Laborbedingungen und vorhandene Felddaten auf. Folgen Sie den Leitfäden zur Serverleistung, sobald der nächste Engpass feststeht. Erfolg bedeutet eine wiederholt schnellere Antwort für den vorgesehenen Besucher mit weiterhin korrektem Inhalt.