Antwortzeit interpretieren: Median, p95 und Richtwerte

Was misst die Antwortzeit eigentlich?

Die HTTP-Antwortzeit (auch Response Time) ist die Zeit zwischen dem Start einer Anfrage und dem vollständigen Eingang der Antwort. Sie ist kein einzelner Wert, sondern die Summe mehrerer Phasen, die nacheinander ablaufen. Wer nur die Gesamtzeit betrachtet, weiß, dass etwas langsam ist, aber nicht wo. Deshalb lohnt der Blick auf die Teilwerte. Die Abgrenzung zur reinen Erreichbarkeit beschreibt Uptime und Antwortzeit: der Unterschied; hier geht es um die Frage, wie Sie die Zahlen lesen.

Mit curl lassen sich die Phasen für eine Adresse nachmessen:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nGesamt: %{time_total}s\n" https://example.com/

Die Werte sind kumulativ: time_connect enthält bereits die DNS-Zeit. Um die Dauer einer Phase zu erhalten, subtrahieren Sie den vorherigen Wert (Beispiel: TLS-Dauer = time_appconnect − time_connect). Die Sofortprüfung im Uptime Checker zeigt die Teilwerte ohne Konto, soweit sie messbar sind.

Warum sind Median und p95 besser als der Durchschnitt?

Antwortzeiten verteilen sich schief: Die meisten Anfragen sind schnell, einige wenige sehr langsam. Der Durchschnitt (arithmetisches Mittel) wird von diesen Ausreißern nach oben gezogen und beschreibt weder das typische noch das schlechte Erlebnis. Besser eignen sich:

• Median: die Hälfte aller Messungen ist schneller, die Hälfte langsamer. Er zeigt das typische Erlebnis.
• 95. Perzentil (p95): 95 % aller Messungen sind schneller als dieser Wert. Er zeigt das schlechte Erlebnis, ohne von einzelnen Extremwerten dominiert zu werden.
• Minimum und Maximum: das Minimum zeigt, was der Server im besten Fall leisten kann, das Maximum den schlimmsten Ausreißer.

UPTIMESHIELD weist Median, p95, Durchschnitt, Minimum und Maximum aus. Wie diese Werte berechnet werden, dokumentiert die Messmethodik.

Welche Richtwerte gibt es?

Allgemeingültige Grenzwerte sind mit Vorsicht zu genießen, weil sie von Technik, Standort und Seitentyp abhängen. Als grobe Orientierung für die serverseitige Antwort (TTFB) nennt web.dev bis etwa 800 ms als gut und über 1,8 Sekunden als schlecht; Werte dazwischen gelten als verbesserungsfähig. Diese Angaben beziehen sich auf reale Nutzer im Browser; für eine einzelne Prüfanfrage von einem Rechenzentrum gelten sie als Anhaltspunkt, nicht als Norm. Die tatsächliche Ladeleistung beschreiben die Core Web Vitals (Quelle unten) mit anderen Messgrößen (etwa Largest Contentful Paint).

Die Tabellenwerte sind keine Messergebnisse, sondern grobe Erfahrungsspannen, die je nach Hosting, Standort und Last abweichen können. Wichtiger als jeder fremde Richtwert ist der eigene Normalverlauf: Beobachten Sie Median und p95 über ein bis zwei Wochen, und werten Sie Abweichungen davon.

Wie setzen Sie sinnvolle Schwellen?

Eine Schwelle sollte ein Verhalten auslösen, das ein Mensch ändern würde. Ein praktisches Vorgehen:

1. Normalverlauf erfassen: Median und p95 über mindestens eine Woche beobachten, inklusive Wochenende und typischer Lastspitzen.
2. Schwelle über dem normalen p95 ansetzen: als Faustregel das Zwei- bis Dreifache, damit gewöhnliche Schwankungen keinen Alarm auslösen.
3. Mehrere Überschreitungen verlangen: Ein einzelner langsamer Wert ist meist Rauschen; mehrere in Folge zeigen ein Muster.
4. Nach einem Jahr überprüfen: Wächst die Seite, steigt der normale Wert.

UPTIMESHIELD markiert Antworten ab 2.000 ms (einstellbar) als „langsam“ und stuft den Monitor dann als „Beeinträchtigt“ ein; ein Langsam-Alarm folgt nach 3 langsamen Prüfungen in Folge. Hat Ihre Seite im Normalfall 200 ms, ist 2.000 ms eine großzügige Schwelle, die Sie auf etwa 800–1.000 ms senken können. Hat sie 1.200 ms, wäre die Voreinstellung eher knapp. Das Zusammenspiel mit Fehlalarmen erläutert Falsche Ausfallalarme vermeiden.

Wie lesen Sie Muster in den Diagrammen?

Statt einzelner Werte zeigt der Verlauf oft aussagekräftige Formen. Die folgende Tabelle ordnet typische Muster plausiblen Ursachen zu; sie sind Hypothesen, keine Diagnosen.

Was macht Antworten langsam, und was hilft?

Die Ursachen lassen sich meist in wenige Gruppen einteilen. Als Entscheidungsregel gilt: Erst die Phase finden, dann die Ursache.

• Wenn DNS oder Verbindungsaufbau hoch sind: Resolver und Entfernung prüfen, Nameserver wechseln oder ein CDN einsetzen. Mehr zur Namensauflösung in DNS-Fehler erkennen und beheben.
• Wenn TLS hoch ist: TLS 1.3 aktivieren, Session-Resumption und OCSP-Stapling prüfen. Jede zusätzliche Roundtrip-Zeit zum Server verlängert den Handshake; deshalb wirkt Entfernung hier besonders stark.
• Wenn TTFB hoch ist: Dies ist der häufigste Fall. Mögliche Maßnahmen: Seiten-Cache aktivieren (Full-Page-Cache, Objekt-Cache), aktuelle PHP-Version nutzen, OPcache aktivieren, Datenbankabfragen und Indizes prüfen, ausreichend PHP-Worker bereitstellen.
• Wenn die Übertragung lang ist: Kompression (gzip oder Brotli) einschalten, Antworten verkleinern, unnötige Daten aus APIs entfernen.

Ein häufig unterschätzter Faktor sind erschöpfte Worker. Hat der Server nur wenige PHP-Prozesse und wartet jede Anfrage auf eine langsame Datenbank, stauen sich neue Anfragen, und die Antwortzeit steigt für alle, ohne dass der Server „kaputt“ wäre. Ein Beispiel für typische PHP-FPM-Einstellungen zur Prüfung:

# /etc/php/8.x/fpm/pool.d/www.conf (Beispielwerte, an Ihren RAM anpassen)
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500
slowlog = /var/log/php-fpm/slow.log
request_slowlog_timeout = 3s

Das slowlog zeigt, welche Skripte länger als drei Sekunden brauchen, und liefert damit die Spur zur eigentlichen Ursache. Prüfen Sie vor dem Erhöhen von pm.max_children immer den verfügbaren Arbeitsspeicher, sonst droht ein Absturz durch Speichermangel.

Ist die Antwortzeit gleich der Ladezeit?

Nein, und diese Verwechslung ist die häufigste Fehlinterpretation. Ein Monitor ruft die Adresse per HTTP auf und misst die Antwort auf diese eine Anfrage. Ein Besucher mit Browser lädt zusätzlich Stylesheets, Skripte, Bilder und Schriften, führt JavaScript aus und stellt die Seite dar. Eine Seite mit einer Antwortzeit von 300 ms kann sich im Browser trotzdem träge anfühlen, wenn große Bilder oder schwere Skripte nachgeladen werden. Umgekehrt liefert eine Single-Page-App oft schnell ein leeres Grundgerüst, bevor Inhalte erscheinen.

Die Messung der Antwortzeit ist deshalb ein Frühwarnindikator für das Servergeschehen, kein Ersatz für Lab- und Felddaten wie Lighthouse oder die Core Web Vitals. Beide Perspektiven ergänzen sich. Zum Umfang der Messung siehe auch Antwortzeit messen.

Welche Fehler passieren bei der Interpretation häufig?

Checkliste: Antwortzeiten sinnvoll auswerten

1. Normalverlauf (Median und p95) über mindestens eine Woche festhalten.
2. Langsam-Schwelle auf etwa das Zwei- bis Dreifache des normalen p95 setzen.
3. Bei Auffälligkeiten zuerst die Phase bestimmen (DNS, TCP, TLS, TTFB, Übertragung).
4. Zeitliche Muster (Uhrzeit, Wochentag, nach Updates) mit Server-Zeitplänen abgleichen.
5. Kritische Seiten einzeln überwachen, nicht nur die Startseite.
6. Für das Nutzererlebnis zusätzlich Core Web Vitals messen.
7. Nach größeren Änderungen (Update, Umzug, neues Plugin) Vorher-Nachher vergleichen.

Grenzen und Einordnung

Die gemessene Antwortzeit hängt vom Messstandort ab: Ein Monitor in Deutschland sieht für einen Server in Frankfurt andere Werte als für einen in Übersee, und das nicht wegen der Serverleistung, sondern der Laufzeit der Datenpakete. Ein Vergleich mit Ihrem eigenen Browser kann deshalb deutlich abweichen. Auch das Intervall begrenzt die Aussage: Bei einer Messung alle fünf Minuten sehen Sie keine Spitzen, die zwischen den Messungen auftreten. Der p95 über wenige Messwerte ist nicht belastbar.

Schließlich sagt die Antwortzeit nicht, warum eine Anwendung langsam ist; dafür braucht es Server- und Anwendungsprotokolle. Wie weit Monitoring von außen reicht, beschreibt Grenzen automatischer Website-Prüfungen. Und für vertragliche Ziele rund um Geschwindigkeit sind klare Definitionen nötig, siehe SLA, SLO und SLI erklärt.

Wie setzen Sie das mit UPTIMESHIELD um?

Jeder HTTP/HTTPS-Monitor erfasst bei jeder Prüfung die Antwortzeit und zeigt Median, p95, Durchschnitt, Minimum und Maximum im Dashboard. Die Rohdaten bleiben je nach Tarif 30 (Solo), 180 (Pro) oder 365 Tage (Max) erhalten, die Tagesstatistik 400 Tage, so dass Sie Trends über Monate vergleichen können. Die Langsam-Schwelle stellen Sie je Monitor ein; der Alarm erfolgt über die gewohnten Benachrichtigungskanäle.

Für einen Anfang genügt ein kostenloses Solo-Konto: Legen Sie Monitore für Startseite und eine kritische Unterseite an, beobachten Sie eine Woche lang Median und p95 und setzen Sie danach die Langsam-Schwelle auf Basis der eigenen Werte. Mit mehreren Messstandorten (Pro und Max, siehe Preise) lässt sich außerdem erkennen, ob eine Langsamkeit regional ist.