Was ist die Antwortzeit einer Website?

Die Antwortzeit beantwortet eine einfache Frage: Wie lange dauert es, nachdem etwas Ihre Website angefragt hat, bis die Antwort ankommt? Ein Überwachungswerkzeug fragt genauso wie ein Browser, nämlich mit einer HTTP-Anfrage, und misst die Wartezeit.

Sie ist eine der wenigen Zahlen, die ein Problem zeigen, bevor es zum Ausfall wird. Eine Website, die am Montag in 300 Millisekunden antwortet und am Freitag in 2.500 Millisekunden, ist zwar noch „erreichbar“, aber etwas hat sich verändert.

Was bei einer Anfrage passiert

Eine einzelne Anfrage durchläuft mehrere Stufen. Jede braucht Zeit, und jede kann aus einem anderen Grund langsam sein.

1. DNS-Abfrage. Der Name example.com wird in eine IP-Adresse übersetzt. Das kann schnell gehen, wenn die Antwort in der Nähe zwischengespeichert ist, und langsam, wenn nicht.
2. TCP-Verbindung. Der Client öffnet eine Verbindung zu dieser Adresse. Die Zeit hängt vor allem von der Entfernung und der Qualität des Netzwerkwegs ab.
3. TLS-Handshake. Bei https-Adressen einigen sich beide Seiten auf die Verschlüsselung, und der Client prüft das Zertifikat des Servers. Das kostet einige weitere Hin- und Rückwege.
4. Anfrage und Verarbeitung auf dem Server. Die Anfrage wird gesendet. Der Server liest unter Umständen Dateien, fragt eine Datenbank ab oder führt Anwendungscode aus, bevor er antworten kann.
5. Erstes Byte. Der erste Teil der Antwort kommt an. Die Zeit bis zu diesem Moment heißt Time to First Byte (TTFB).
6. Rest der Antwort. Die übrigen Daten werden übertragen.

Weiterleitungen kommen hinzu. Antwortet die Adresse mit einer Weiterleitung, wiederholt der Client die Stufen für die nächste Adresse. Eine Kette von Weiterleitungen vervielfacht die Kosten.

Time to First Byte und Gesamtzeit

Am häufigsten werden zwei Zahlen verwendet:

• Time to First Byte (TTFB) ist die Wartezeit, bis das erste Byte der Antwort ankommt. Wie weit zurück sie beginnt, hängt vom Werkzeug ab. Die Leitlinien zur Web-Performance auf web.dev zählen sie ab dem Beginn der Navigation, was Weiterleitungen, DNS-Abfrage, Verbindungsaufbau, TLS-Aushandlung und das Warten auf den Server einschließt. Manche Werkzeuge messen erst ab dem Moment, in dem die Anfrage gesendet wird, wodurch die Aufbaustufen entfallen. Wenn Sie Zahlen verschiedener Werkzeuge vergleichen, prüfen Sie, welche Definition jedes verwendet.
• Die Gesamtantwortzeit ist die Zeit, bis die Antwort vollständig empfangen wurde. Bei einer einfachen Seitenprüfung kommt zur TTFB die Übertragung der Antwort hinzu.

Eine hohe TTFB bei schnellen Verbindungsstufen weist auf den Server oder die Anwendung dahinter. Langsame DNS- oder Verbindungsstufen weisen auf den Nameserver oder das Netzwerk.

Antwortzeit und Latenz

Latenz ist die Verzögerung, die das Netzwerk selbst hinzufügt, vor allem die Zeit, die ein Signal für den Weg braucht. Die Entfernung zählt: Eine Anfrage von Singapur an einen Server in Frankfurt dauert länger als eine aus Berlin, auch wenn der Server gleich schnell ist. Die Antwortzeit umfasst die Latenz plus die Arbeit des Servers.

Antwortzeit ist nicht Seitenladezeit

Eine Überwachungsprüfung fordert eine einzelne Adresse an und misst die Antwort. Sie verhält sich nicht wie ein Browser, der eine Seite öffnet.

Ein Browser lädt zusätzlich Bilder, Stylesheets, Skripte und Schriftarten herunter, führt die Skripte aus und zeichnet die Seite. Kennzahlen für dieses Erlebnis, etwa Largest Contentful Paint oder die Core Web Vitals, beschreiben, was ein Besucher sieht und wann. Dafür braucht es einen echten Browser.

Eine Seite kann eine schnelle Serverantwort haben und sich wegen umfangreicher Skripte oder großer Bilder trotzdem langsam anfühlen. Auch das Gegenteil ist möglich. Deshalb liest man die HTTP-Antwortzeit am besten als Maß für den Server und den Weg dorthin, nicht für alles, was ein Besucher erlebt. UptimeWire misst Ersteres. Es führt keinen Browser aus und meldet keine Core Web Vitals.

Warum sich die Antwortzeit ändert

• Datenverkehr. Mehr gleichzeitige Besucher konkurrieren um dieselben Ressourcen.
• Aufwendige Hintergrundarbeit. Backups, Importe oder geplante Jobs können Besuchern Kapazität wegnehmen.
• Langsame Datenbankabfragen. Eine Abfrage, die bei kleinen Datenmengen schnell war, kann mit wachsenden Daten langsamer werden.
• Caching. Eine zwischengespeicherte Seite kann um ein Vielfaches schneller sein als eine, die auf Anforderung erzeugt wird.
• Änderungen an der Website. Ein Release, ein Plugin oder ein neuer Aufruf bei einem Drittanbieter kann über Nacht Zeit kosten.
• Das Netzwerk. Überlastung und geänderte Routen beeinflussen die Verbindungszeit und können je nach Tageszeit schwanken.
• Wo die Prüfung läuft. Die Entfernung zum Server zählt, wie oben beschrieben.

Von verschiedenen Orten prüfen

Eine Messung sagt, wie die Website von einem Ort aus antwortet. Dienste, die von mehreren Standorten prüfen, können zeigen, ob eine langsame Antwort global oder regional ist. Ein Server, der nahe an seinem Rechenzentrum in 200 Millisekunden antwortet und von der anderen Seite der Welt in 900 Millisekunden, verhält sich normal. Eine Website, die überall langsam ist, weist auf den Server.

Wenn Sie Zahlen über die Zeit vergleichen, halten Sie Ort und Intervall konstant. Sonst kann eine Änderung der Zahl von der Methode kommen und nicht von der Website.

Ein durchgerechnetes Beispiel

Eine Prüfung einer https-Adresse erfasst:

Das erste Byte ab dem Beginn der Prüfung gerechnet, begann die Antwort nach 312 Millisekunden einzutreffen, davon gingen 83 Millisekunden in den Aufbau (18 + 24 + 41). Die übrigen 229 Millisekunden entfallen grob auf den Weg der Anfrage zum Server, die Vorbereitung der Antwort auf dem Server und den Rückweg des ersten Bytes. Zeigt die Prüfung am nächsten Tag 1.180 ms bis zum ersten Byte bei unveränderten Aufbaustufen, liegt die zusätzliche Zeit im Server und nicht in DNS oder im Netzwerk.

Wie ein guter Wert aussieht

Es gibt keinen einzigen richtigen Wert. Die Leitlinien von web.dev zur TTFB, gedacht für Seiten, die Besucher im Browser laden, nennen 0,8 Sekunden oder weniger als groben Richtwert für „gut“ und mehr als 1,8 Sekunden für „schlecht“. Verstehen Sie das als Orientierung und nicht als Ziel für jede Website. Eine API, die andere Systeme aufrufen, muss möglicherweise weit schneller antworten. Eine Seite mit aufwendiger serverseitiger Arbeit darf vernünftigerweise länger brauchen.

Der nützlichere Vergleich ist die Website mit ihrem eigenen Normalwert: Was ist typisch, und wie weicht der heutige Wert davon ab?

Antwortzeit in UptimeWire

UptimeWire sendet eine HTTP-Anfrage an jede Website-Adresse, die Sie einrichten, und erfasst die benötigte Zeit zusammen mit dem Ergebnis. Das erste Byte wird ab dem Beginn der Prüfung gezählt, schließt also die Aufbaustufen und etwaige Weiterleitungen ein, und die Gesamtzeit umfasst die ganze Prüfung.

Die Aufschlüsselung nach Stufen gehört zum detaillierten Prüfbericht, der ab dem Tarif Starter verfügbar ist. Im Tarif Free sehen Sie die Antwortzeit jeder Prüfung ohne die Aufteilung in Stufen.