So prüfen Sie die Server-Antwortzeit

Antwortzeit, TTFB und Ladezeit sind nicht dieselbe Zahl

Sie werden oft synonym verwendet, beantworten aber unterschiedliche Fragen:

• Verbindungszeit ist DNS-Auflösung plus TCP-Handshake plus TLS-Handshake. Sie hängt vor allem von Distanz und Netzwerkqualität ab, der eigene Code des Servers hat damit nichts zu tun.
• Time to First Byte (TTFB) ist der Moment, in dem das erste Byte der Antwort eintrifft, gemessen ab dem Start der Anfrage. Sie umfasst die Verbindungszeit plus die Verarbeitung durch den Server: Routing, Datenbankabfragen, Template-Rendering, alle vorgelagerten API-Aufrufe.
• Server-Verarbeitungszeit ist TTFB minus Verbindungszeit. Das ist der Teil, den Sie in Ihrer Anwendung beheben können.
• Ladezeit der Seite ist alles: das HTML, dann jedes Bild, jedes Stylesheet, jedes Skript und jede Schriftart, die der Browser lädt, plus die Arbeit, sie darzustellen. Eine Seite kann eine hervorragende TTFB haben und trotzdem acht Sekunden zum Laden brauchen.

Wer diese Begriffe verwechselt, optimiert am falschen Ende. Bilder zu komprimieren bringt nichts gegen eine langsame Datenbankabfrage, und eine schnellere Datenbank bringt nichts für eine Seite mit vier Megabyte JavaScript.

Messen mit curl

curl gibt jede Phase einzeln aus, wodurch Sie die Verbindungskosten mit einem einzigen Befehl von den Serverkosten trennen können:

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

Alle Werte sind Sekunden ab dem Start der Anfrage, jeder schließt also die vorherigen mit ein. Die Server-Verarbeitungszeit ist ttfb minus tls, oder minus connect bei reinem HTTP. Führen Sie den Befehl drei- oder viermal aus: Die erste Anfrage zahlt womöglich für einen kalten Cache oder eine neue Verbindung, und eine einzelne Messung ist keine Messung.

Zwei Dinge sollten Sie auseinanderhalten. Das misst nur das HTML-Dokument, nicht die Seite, es wird also immer schneller wirken als ein Browsertest. Und eine ungecachte, angemeldete oder Suchseite ist oft deutlich langsamer als die Startseite, messen Sie also die URL, die Sie wirklich interessiert, statt /.

Was als normal gilt

Es gibt keinen allgemeingültigen Schwellenwert. Diese Bandbreiten sind ein brauchbarer Richtwert für eine Dokumentanfrage, gemessen von einem Standort nahe Ihren Besuchern:

• Unter 200 ms. Schnell. Typisch für statische Inhalte, einen warmen Cache oder einen CDN-Edge-Standort, der direkt antwortet.
• 200 bis 500 ms. Normal für eine dynamische Seite, die eine Datenbank abfragt. Das fällt niemandem auf.
• 500 ms bis 1 s. Spürbar. Meist eine Abfrage, die einen Index braucht, ein ungecachtes Template oder ein langsamer vorgelagerter Aufruf.
• 1 bis 3 s. Nutzer spüren es, und Suchmaschinen messen es. Es lohnt sich, das als Mangel zu behandeln.
• Über 3 s. Etwas stimmt nicht: ein überlasteter Server, eine Sperre, ein vorgelagerter Dienst mit Timeout, oder eine Anfrage, die deutlich mehr Arbeit verrichtet, als sie sollte.

Der weitaus nützlichere Vergleich ist der mit sich selbst. Eine Seite, die letzten Monat in 300 ms antwortete und heute in 900 ms antwortet, hat eine konkrete Ursache, die dazwischen eingeführt wurde, und das zu wissen ist mehr wert als jeder veröffentlichte Benchmark.

Warum es je nach Standort variiert

Distanz kostet Zeit und lässt sich nicht wegoptimieren. Jeder Round Trip zwischen Client und Server dauert mindestens so lange, wie der physische Weg erlaubt, und eine TLS-Verbindung braucht mehrere Round Trips, bevor das erste Byte der Antwort überhaupt starten kann. Deshalb kann derselbe Server lokal in 150 ms und von einem anderen Kontinent aus in 700 ms antworten, während er exakt dieselbe Arbeit verrichtet.

Routing spielt ebenfalls eine Rolle und ist weniger vorhersehbar als Distanz: Traffic zwischen zwei Netzwerken kann einen schlechten Pfad nehmen, der nur für eine Region zusätzliche Latenz verursacht und für keine andere. Wenn Sie ein CDN verwenden, werden manche Standorte aus einer nahegelegenen gecachten Kopie bedient, während andere den Cache verfehlen und die volle Strecke zum Ursprungsserver zahlen, was zu einer großen Streuung zwischen den Standorten für dieselbe URL führt.

Messen Sie also von dort, wo Ihre Nutzer sind, nicht von dort, wo Ihr Server steht, und vergleichen Sie Gleiches mit Gleichem. Eine Zahl ohne zugehörigen Standort ist mit nichts vergleichbar.

Wenn langsam gleichbedeutend mit defekt ist

Manche Langsamkeit ist eher eine Warnung als ein Leistungsproblem:

• Eine Antwortzeit, die unter Last stetig wächst, bedeutet, dass der Server überlastet ist. Das endet in Timeouts, nicht nur in langsamen Seiten.
• Zeiten, die sich exakt bei 30 oder 60 Sekunden häufen, sind Timeouts, keine Langsamkeit. Etwas vorgelagertes antwortet nicht, und ein Proxy wartet sein Limit aus, bevor er mit einem 504 aufgibt.
• Meistens schnell, mit gelegentlichen starken Spitzen, deutet meist auf eine Sperre, einen Cron-Job, eine Datensicherung oder einen ablaufenden Cache hin, den jede Anfrage gleichzeitig neu aufbaut.
• Nur für angemeldete Nutzer langsam bedeutet, dass der Cache den anonymen Traffic trägt und darunter eine wirklich langsame Anwendung verbirgt.
• Nur aus einer Region langsam ist ein Netzwerk- oder CDN-Problem, kein Anwendungsproblem, und keine noch so große Arbeit am Backend wird das beheben.

Den Tag bemerken, an dem es sich geändert hat

Eine einzelne Messung sagt Ihnen, was für eine Anfrage, von einem Ort, zu einem Zeitpunkt passiert ist, und die Antwortzeit ist genau die Art von Metrik, die driftet statt abrupt auszufallen. Geplante Prüfungen messen dieselbe URL fortlaufend von denselben Standorten, bewahren die Historie, damit Sie auf den Tag der Änderung zeigen können, und alarmieren, wenn die Zeit einen Schwellenwert überschreitet, statt wenn sich ein Kunde beschwert. HostTracker führt diese Prüfungen von über 300 Prüfpunkten in 158 Städten aus, sodass eine regionale Verlangsamung als solche sichtbar wird. Führen Sie jetzt eine Prüfung mit dem HTTP-Prüfungstool aus. Wenn der Server schnell ist und die Seite trotzdem nicht, steht der Rest der Antwort unter So prüfen Sie die Website-Geschwindigkeit.