TTFB vs. Antwortzeit vs. Latenz: was jede Größe misst

Was jeder Begriff bedeutet

Netzwerklatenz, oft als Round-Trip-Time angegeben, ist die Zeit, die ein Paket auf dem Weg zum Server und zurück verbringt, ohne dass dazwischen Anwendungsarbeit stattfindet. Sie wird durch die physische Distanz, die Anzahl der Hops und die Qualität der Route bestimmt. Nichts, was Sie in Ihrem Code tun, ändert sie.

Time to First Byte (TTFB) wird von dem Moment an gemessen, in dem der Client die Anfrage startet, bis das erste Byte der Antwort bei ihm eintrifft. Diese Spanne enthält die DNS-Auflösung, den TCP-Verbindungsaufbau, den TLS-Handshake, die Zeit, die die Anfrage unterwegs verbringt, was auch immer der Server tut, um eine Antwort zu erzeugen, und den Rückweg. TTFB ist daher immer größer als eine einzelne Round-Trip-Zeit, meist um ein Mehrfaches.

Antwortzeit ist der unschärfste der drei Begriffe. Die meisten Monitoring-Tools verwenden ihn für die Gesamtzeit bis zum Abschluss der Anfrage, vom ersten Paket bis zum letzten Byte des Antwortkörpers. Manche Tools verwenden ihn als Synonym für TTFB. Bevor Sie zwei mit "Antwortzeit" bezeichnete Zahlen vergleichen, prüfen Sie, an welcher Stelle das jeweilige Tool die Uhr angehalten hat.

Wie jede Größe gemessen wird

Latenz stammt aus einem ICMP-Echo, das ist, was ping sendet, oder aus der Zeitmessung des TCP-Handshakes, wenn ICMP blockiert ist. TTFB und Gesamtzeit stammen vom HTTP-Client selbst. Ein einziger curl-Aufruf gibt alle Grenzwerte aus:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Jeder Wert ist kumulativ ab dem Start der Anfrage, Sie lesen sie also als Grenzpunkte, nicht als Dauern. Ziehen Sie den vorherigen Wert ab, um die Länge einer Phase zu erhalten.

Welche Zahl Ihr Tool Ihnen zeigt

Jedes Tool meldet einen anderen Ausschnitt derselben Anfrage, was der übliche Grund ist, warum zwei Messungen derselben Website nicht übereinstimmen:

• ping meldet ausschließlich die Round-Trip-Latenz, ohne jede Serverarbeit
• curl -w meldet alle oben genannten Grenzwerte, was es zur Referenz macht, wenn Zahlen voneinander abweichen
• Entwicklertools im Browser zeigen TTFB als Wartephase einer Anfrage, getrennt von der darunterliegenden Downloadphase
• Lighthouse und PageSpeed melden die Server-Antwortzeit, was bei der Dokumentanfrage der TTFB entspricht
• Uptime-Monitore melden eine Antwortzeit, deren Definition je nach Produkt variiert und die den Verbindungsaufbau ab dem Ort einschließt, von dem die Prüfung ausging
• Real User Monitoring meldet die TTFB aus dem Feld, aggregiert über echte Besucher in echten Netzwerken

Wie eine gute Zahl aussieht

Die Latenz ist geografisch begrenzt. Unter 30 ms sind innerhalb eines Ballungsraums normal, 50 bis 100 ms über einen Kontinent hinweg und 150 bis 250 ms zwischen Kontinenten. Eine Route, die deutlich schlechter misst, als es die Distanz erwarten lässt, deutet eher auf einen schlechten Pfad als auf einen langsamen Server hin.

Für TTFB stuft web.dev 800 ms oder weniger als gut ein und alles über 1,8 Sekunden als schlecht, während Lighthouses Prüfung der Server-Antwortzeit oberhalb von 600 ms als fehlgeschlagen gilt. Streben Sie unter 600 ms für die Dokumentanfrage an und behandeln Sie 200 ms als Zielwert für alles, was gecacht oder statisch ausgeliefert wird.

Die gesamte Antwortzeit hängt von der Größe dessen ab, was Sie senden, es gibt also keine allgemeingültige Zahl. Messen Sie Ihre eigene Basislinie an einem normalen Tag und behandeln Sie die Abweichung davon als das Signal, nicht den absoluten Wert.

Die Abstände lesen

Die einzelnen Zahlen zählen weniger als der Abstand zwischen ihnen, denn jede Lücke zeigt auf ein anderes Teilsystem:

• TTFB minus Round-Trip-Latenz ist ungefähr die Zeit, die der Server mit Nachdenken verbracht hat. Ist das der größte Anteil, liegt das Problem im Anwendungscode, an einer langsamen Abfrage oder einem kalten Cache
• Connect minus DNS-Auflösung ist ein Round Trip für den TCP-Handshake. Ist er deutlich größer als Ihre gemessene Latenz, ist der Netzwerkpfad überlastet oder falsch geroutet
• TLS minus Connect sind die Handshake-Kosten, typischerweise ein oder zwei zusätzliche Round Trips, und ein hoher Wert deutet auf Probleme mit der Zertifikatskette oder der Session-Wiederaufnahme hin
• Total minus TTFB ist die Übertragungszeit. Dominiert dieser Wert, ist die Antwort zu groß oder die Verbindung zu langsam, und keine Serveroptimierung wird helfen
• Die DNS-Auflösung allein sollte, einmal gecacht, wenige Millisekunden betragen. Eine dauerhaft langsame Auflösung ist ein Problem des Resolvers oder des autoritativen Nameservers, nicht des Webservers

Dieselbe Lesart funktioniert auch umgekehrt, wenn nur ein Standort langsam ist. Ist die Denkzeit des Servers überall gleich und liegt der Unterschied vollständig in Latenz und Übertragung, ist der Server in Ordnung und die Route nicht. Führen Sie die Prüfung von mehreren Orten aus, bevor Sie an der Anwendung etwas ändern.

Alles an einem Ort messen

Um diese Zahlen für eine Seite zu sehen, ohne sie von Hand zusammenzutragen, führen Sie den Seitengeschwindigkeitstest aus, der die Seite von einem externen Standort lädt und den Ladevorgang in seine Phasen aufschlüsselt. Die Anleitung zur Server-Antwortzeit behandelt dieselbe Messung von der Kommandozeile aus. Ein einzelner Durchlauf sagt nur etwas über diesen einen Moment aus. Wenn die Zahl also wichtig ist, richten Sie eine geplante Prüfung dafür ein: HostTracker misst die Antwortzeit bei jeder Prüfung von über 300 Prüfpunkten in 158 Städten, und genau das macht aus einer einzelnen Messung eine Basislinie, an der Sie eine Verschlechterung erkennen können. Weitere Begriffserklärungen finden Sie im Bereich zu Monitoring-Begriffen.