„Time To First Byte“ wird oft als Maßstab dafür verwendet, wie schnell ein Webserver auf eine Anfrage reagiert, und von gängigen Webtest-Anbietern gemessen. Je kürzer TTFB ist, desto besser ist der Webserver (in der Theorie). Aber die Theorie ist nicht sehr gut.
Wikipedia definiert „Time To First Byte“ als „die Zeitdauer von der HTTP-Anfrage des virtuellen Nutzers bis zum Empfang des ersten Bytes der Seite durch den Browser.“ Aber was zeigen beliebte Webseitentest-Anbieter tatsächlich an? Um das herauszufinden, haben wir einen Testserver gebaut, der Verzögerungen in die HTTP-Antwort einfügt, um festzustellen, was wirklich gemessen wird. Die Antwort war eine große Überraschung und hat gezeigt, dass TTFB kein hilfreicher Maßstab ist.
Wenn ein Webbrowser eine Seite von einem Webserver anfordert, sendet er die Anfrage selbst sowie einige Header, die Dinge wie die zulässigen Formate für die Antwort angeben. Der Server antwortet mit einer Statuszeile (typischerweise „HTTP/1.1 200 OK“, was anzeigt, dass die Seite verfügbar ist), gefolgt von weiteren Headern (die Informationen über die Seite enthalten) und schließlich dem Inhalt der Seite.
Der TTFB-Testserver von Cloudflare verhält sich ein wenig anders. Wenn er eine Anfrage erhält, sendet er den ersten Buchstaben von „HTTP/1.1 200 OK“ (das H) und wartet dann 10 Sekunden lang, bevor er den Rest der Header und der Seite selbst sendet. (Sie können den Code für den TTFB-Server hier herunterladen; er ist in Go geschrieben.)
Wenn man WebPageTest bittet, eine Seite von Cloudflares TTFB-Server herunterzuladen, erhält man folgende Überraschung. WebPageTest meldet die Time To First Byte als die Zeit, zu der das H empfangen wurde (und nicht als die Zeit, zu der die Seite selbst tatsächlich gesendet wurde). Durch die Wartezeit von 10 Sekunden wird dies deutlich.
Die gemeldete TTFB ist nicht der Zeitpunkt des ersten Datenbytes der Seite, sondern der des ersten Bytes der HTTP-Antwort. Dabei handelt es sich um zwei sehr unterschiedliche Dinge, da die Antwort-Header sehr schnell generiert werden können. Es sind aber die Daten, die den allerwichtigsten Messwert beeinflussen: wie schnell der Benutzer die Seite sehen kann.
Bei Cloudflare setzen wir ausgiebig nginx ein. Bei der Untersuchung von TTFB sind wir auf einen signifikanten Unterschied in der TTFB von nginx gestoßen, je nachdem, ob Kompression verwendet wird oder nicht. Die gzip-Kompression von Webseiten reduziert die Zeit erheblich, die eine Webseite zum Herunterladen benötigt, aber diese Kompression hat ihren Preis. Der Preis besteht darin, dass TTFB größer wird, obwohl der komplette Download schneller abläuft.
Um das zu veranschaulichen, haben wir die umfangreichste Wikipedia-Seite (List of Advanced Dungeons and Dragons 2nd Edition Monsters) genommen und sie unter Verwendung von nginx mit und ohne aktivierte gzip-Kompression bereitgestellt. Die folgende Tabelle zeigt die TTFB und die gesamte Downloadzeit mit aktivierter und deaktivierter Kompression.
| TTFB | Seite geladen
---------------------------- | -------- | -------------
Keine Kompression (gzip aus) | 213 µs | 43 ms
Mit Kompression (gzip ein) | 1,7 ms | 8 ms
Beachten Sie, dass die Seite mit gzip-Kompression 5-mal schneller heruntergeladen wurde, TTFB dabei aber 8-mal größer war. Das liegt daran, dass nginx vor dem Senden der HTTP-Header wartet, bis die Kompression begonnen hat; wenn die Kompression deaktiviert ist, sendet es die Header sofort. Wenn man sich also TTFB ansieht, scheint es, als wäre Kompression eine schlechte Idee. Aber wenn man sich die Downloadzeit ansieht, sieht man genau das Gegenteil.
Aus der Sicht des Endanwenders ist TTFB nahezu nutzlos. In diesem (realen) Beispiel ist es tatsächlich negativ mit der Downloadzeit korreliert: Je schlechter die TTFB, desto besser die Downloadzeit. Bei einem Blick in den nginx-Quellcode stellten wir fest, dass wir schummeln und die Header schnell versenden könnten, damit es so aussieht, als wäre unser TTFB auch mit Kompression fantastisch. Letztendlich entschieden wir uns aber, das nicht zu tun: Es hätte sich ebenfalls negativ auf die Endanwendererfahrung ausgewirkt, weil wir genau dann ein wertvolles Paket verschwendet hätten, wenn TCP sowieso langsam startet. Es hätte Cloudflare in einigen Tests gut aussehen lassen, aber dem Endanwender tatsächlich geschadet.
Wahrscheinlich ist TTFB nur dann nützlich, wenn man sie als Trend betrachtet. Und sie wird am besten am Server selbst gemessen, sodass die Netzwerklatenz eliminiert wird. Durch die Untersuchung eines Trends kann man erkennen, ob es ein Problem auf dem Webserver gibt (z. B. Überlastung).
Wenn man TTFB aus der Ferne misst, bedeutet das, dass man gleichzeitig auch die Netzwerklatenz misst. Dadurch verschleiert man aber, was TTFB eigentlich messen soll: wie schnell der Webserver auf eine Anfrage reagieren kann.
Für Cloudflare ist TTFB kein signifikanter Messwert. Wir sind daran interessiert, die Erfahrung für Endanwender zu optimieren, d. h. die tatsächliche Zeitdauer, bis die Seite für den Endanwender sichtbar ist, möglichst kurz zu halten. Wir werden Tools speziell für die Überwachung der Endanwender-Erfahrung einführen, damit alle unsere Nutzer sehen und messen können, was ihre Besucher erleben.