Uptime vs. Antwortzeit: Unterschied, Messung, Zusammenspiel

Was ist der Unterschied zwischen Uptime und Antwortzeit?

Uptime ist ein Anteil: Wie viel Prozent der Zeit war die Website erreichbar und hat korrekt geantwortet? Antwortzeit ist eine Dauer: Wie viele Millisekunden vergehen zwischen Anfrage und Antwort? Die eine Größe ist binär (erreichbar oder nicht) und wird über die Zeit verdichtet, die andere ist stetig und hat eine Verteilung.

Die Grundlagen zur Uptime stehen in Was bedeutet Uptime?, die Rechnung in Website-Verfügbarkeit berechnen. Dieser Artikel zeigt, wie beide Werte zusammenwirken.

Woraus setzt sich die HTTP-Antwortzeit zusammen?

Eine Anfrage durchläuft mehrere Phasen, die einzeln gemessen werden können. Wer nur die Gesamtzeit kennt, sieht nicht, wo die Zeit bleibt.

Per Kommandozeile lassen sich die Phasen sichtbar machen. Der folgende Aufruf gibt die kumulierten Zeiten aus:

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

Die Werte sind kumuliert (TTFB enthält DNS, TCP und TLS). Für die reine Serververarbeitung ziehen Sie time_appconnect von time_starttransfer ab. Eine ausführliche Einordnung der einzelnen Zahlen finden Sie in Antwortzeit interpretieren: TTFB, Median und p95.

Warum sind Median und p95 aussagekräftiger als der Durchschnitt?

Antwortzeiten sind schief verteilt: Die meisten Anfragen sind schnell, wenige sehr langsam. Der Durchschnitt wird von diesen Ausreißern nach oben gezogen und beschreibt weder den typischen noch den schlechten Fall.

• Median (p50): Die Hälfte der Messungen ist schneller, die Hälfte langsamer. Er beschreibt den typischen Fall.
• p95: 95 % der Messungen sind schneller als dieser Wert; jede zwanzigste Anfrage ist mindestens so langsam. Er zeigt, wie schlecht es für den unglücklichen Besucher wird.
• Minimum/Maximum: Das Minimum ist der Idealfall ohne Störung, das Maximum meist ein einzelner Ausreißer und selten handlungsleitend.

Wie hängen Uptime und Antwortzeit zusammen?

Auf den ersten Blick sind sie getrennt, in der Praxis aber auf drei Wegen verknüpft:

1. Zeitlimit: Ein Monitor wartet nur eine begrenzte Zeit auf die Antwort. Ist der Server überlastet und antwortet nicht innerhalb des Limits, ist die Prüfung ein Fehlschlag – die Langsamkeit wird zum Ausfall und senkt die Uptime.
2. Früher Indikator: Steigende Antwortzeiten gehen einem Ausfall oft voraus: Die Datenbank wird träge, der Speicher füllt sich, die Last steigt. Wer den Verlauf beobachtet, bekommt Vorwarnung, bevor die Uptime leidet.
3. Gemeinsame Ursachen: Überlast, defekte Plugins, voller Datenträger oder ein überforderter Hoster erzeugen zuerst Langsamkeit, dann Fehler (503, 504, Timeouts) – siehe HTTP-Statuscodes erklärt.

Die Wirkung in umgekehrter Richtung gilt nicht: Eine hohe Uptime sagt nichts über Geschwindigkeit. Ein Monitor mit 30 Sekunden Zeitlimit würde eine Seite, die 25 Sekunden braucht, als „erreichbar“ werten, während kaum ein Besucher so lange wartet.

Welche Antwortzeit ist gut, welche zu langsam?

Eine allgemeingültige Schwelle gibt es nicht; sie hängt von Seitentyp, Standort des Servers und Messpunkt ab. Als grobe Orientierung für die reine Serverantwort (TTFB inklusive Verbindungsaufbau) bei einer typischen Website:

Diese Stufen sind Erfahrungswerte, keine Normwerte. Google nennt für Core Web Vitals eigene Grenzwerte für das Nutzererlebnis (siehe Quellen), die aber nicht die reine Serverantwort betreffen. Entscheidend ist der Verlauf: Eine Seite, die seit Monaten bei 400 ms liegt und plötzlich bei 1.200 ms, hat ein Problem – auch wenn 1.200 ms „noch akzeptabel“ klingen.

Was misst die HTTP-Antwortzeit nicht – und was sind die Core Web Vitals?

Ein Monitor ruft eine URL ab und misst die Dauer dieser Anfrage. Ein Browser tut deutlich mehr: Er lädt zusätzlich CSS, JavaScript, Schriften und Bilder, führt Skripte aus und baut die Seite auf. Die Ladezeit im Browser ist deshalb fast immer um ein Vielfaches höher als die HTTP-Antwortzeit des Servers.

• LCP (Largest Contentful Paint): Wann ist der größte sichtbare Inhalt geladen?
• INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Klicks und Eingaben?
• CLS (Cumulative Layout Shift): Wie stabil ist das Layout, ohne dass Elemente springen?

Diese Kennzahlen entstehen im Browser, idealerweise aus echten Nutzerdaten, und lassen sich mit einem HTTP-Monitor nicht ermitteln. Die TTFB ist allerdings eine Voraussetzung: Eine langsame Serverantwort verzögert alles, was danach kommt. Für die Betrachtung des Serverbeitrags sind HTTP-Messungen ideal, für das Gesamterlebnis ergänzen Sie Browser-Messungen (Antwortzeit messen).

Wie finden Sie die Ursache einer langsamen oder wechselhaften Antwortzeit?

Die folgende Entscheidungslogik hat sich im Betrieb bewährt:

• DNS-Zeit hoch? Nameserver wechseln oder Eintrags-TTL und CNAME-Ketten prüfen (DNS-Fehler erkennen und beheben).
• Verbindungs-/TLS-Zeit hoch? Entfernung zum Server, fehlendes TLS 1.3, überlange Zertifikatskette, fehlende Keep-Alive-Verbindungen prüfen.
• TTFB hoch, Rest normal? Das Problem liegt in der Anwendung: Seitencache fehlt, Datenbankabfragen sind langsam, PHP-Worker sind erschöpft.
• Übertragungszeit hoch? Antwort zu groß: Kompression (gzip/Brotli) aktivieren, Antwortgröße reduzieren.
• Nur p95 hoch, Median normal? Gelegentliche Lastspitzen: Cronjobs, Backups, Crawler, Cache-Leerung zur selben Uhrzeit.
• Immer um dieselbe Uhrzeit langsamer? Zeitgesteuerte Aufgaben oder Nachbarn auf dem Shared Server.

Caching ist oft der größte einzelne Hebel für die TTFB; die Grundlagen stehen in Cache-Control richtig setzen.

Wie sieht das Zusammenspiel in einem Praxisfall aus?

Der Fall zeigt das Muster: Antwortzeit ist der Frühindikator, Uptime der Zeuge im Nachhinein. Beobachten Sie daher beides im selben Dashboard und schauen Sie bei jeder Abweichung zuerst auf die Teilzeiten.

Wie setzen Sie Schwellen und Alarme für die Antwortzeit?

Alarme auf Antwortzeit sind heikel, weil Langsamkeit schwankt. Ein paar Regeln:

• Schwelle aus dem Normalbetrieb ableiten: Messen Sie eine Woche, nehmen Sie den p95 und legen Sie die Schwelle deutlich darüber – nicht bei einem gefühlten „schnell genug“.
• Mehrere Überschreitungen verlangen: Ein einzelner langsamer Wert ist selten relevant. Drei aufeinanderfolgende sind es eher.
• Zeitfenster berücksichtigen: Bekannte Lastzeiten (Backup, Newsletter-Versand) erzeugen erwartbare Spitzen. Ruhezeiten für Langsam-Alarme vermeiden nächtliche Nachrichten, wo sie nicht nötig sind (Benachrichtigungen richtig einrichten).
• Ausfall und Langsamkeit trennen: Ein Ausfall braucht sofortige Reaktion, Langsamkeit meist eine Analyse am nächsten Werktag.
• Seitentypen trennen: Die Startseite (gecacht) und ein API-Endpunkt (dynamisch) haben unterschiedliche Normalwerte und benötigen eigene Schwellen.

Weitere Hinweise zur Einordnung der Werte und zu typischen Auffälligkeiten finden Sie im Ratgeber Falsche Ausfallalarme vermeiden.

Welche Rolle spielen Messstandort und Tageszeit?

Dieselbe Seite liefert je nach Standort und Zeit andere Antwortzeiten. Ein Monitor in Deutschland misst für eine Seite auf einem deutschen Server kurze Wege; ein Besucher aus Übersee erlebt mehr Netzlaufzeit. Tagsüber teilen sich mehr Nutzer die Ressourcen als nachts. Deshalb gilt: Vergleichen Sie Werte immer vom selben Standort und über denselben Zeitraum, und betrachten Sie Veränderungen statt absoluter Zahlen. Mit mehreren Standorten erkennen Sie außerdem, ob eine Verlangsamung nur einen Teil der Nutzer trifft.

Häufige Fehler beim Betrachten von Uptime und Antwortzeit

Grenzen und Einordnung

Eine Antwortzeit-Messung per HTTP ist eine Momentaufnahme von einem Standort. Sie misst die Dauer einer Anfrage, nicht das Erlebnis eines Besuchers mit Mobilfunknetz, älterem Gerät und vollem Seitenaufbau. Der Wert hängt außerdem vom Messpunkt ab: Ein Monitor in Frankfurt sieht andere Zeiten als ein Besucher in Wien oder Zürich. Gleichzeitig bleibt Uptime ein grober Indikator, der Teilausfälle und Langsamkeit nur dann erfasst, wenn Sie Zeitlimit, Statuscodes und Inhaltsprüfung entsprechend einstellen. Beide Werte zusammen liefern ein belastbareres Bild als jeder allein, ersetzen aber weder Echtnutzer-Daten noch eine Browser-Analyse. Mehr dazu in Grenzen automatischer Website-Prüfungen.

Checkliste: Uptime und Antwortzeit gemeinsam im Blick behalten

1. Für jede kritische Adresse einen Monitor mit Zeitlimit und Erfolgsdefinition anlegen.
2. Die Langsam-Schwelle am Normalwert ausrichten (Median im Normalbetrieb plus Puffer).
3. Wöchentlich Median und p95 mit der Vorperiode vergleichen.
4. Bei Auffälligkeiten Teilzeiten (DNS, TLS, TTFB) prüfen, nicht nur die Gesamtzeit.
5. Ergänzend Core Web Vitals aus Echtnutzer- oder Labordaten betrachten.
6. Nach Änderungen (Update, Relaunch, Hosterwechsel) Antwortzeit vorher/nachher vergleichen (Relaunch und Umzug überwachen).
7. Langsam-Alarme nur bei wiederholter Überschreitung auslösen, nicht bei Einzelwerten.

Wie setzen Sie beides mit UPTIMESHIELD um?

UPTIMESHIELD misst bei jeder Prüfung die Gesamtdauer der Anfrage inklusive Weiterleitungen und zeigt die Teilwerte (DNS, Verbindung, TLS, TTFB) an, soweit sie messbar sind. Ausgewertet werden Median, p95, Durchschnitt, Minimum und Maximum – die Statistiken basieren ausschließlich auf erfolgreichen Prüfungen. Als „beeinträchtigt“ gilt eine erreichbare Seite ab 2.000 ms (einstellbar); ein Langsam-Alarm wird nach 3 aufeinanderfolgenden langsamen Prüfungen ausgelöst, damit Einzelwerte keine Alarmflut verursachen. Der Sofort-Report führt ohne Konto drei Messungen durch und zeigt den Geschwindigkeits-Score; für den Verlauf legen Sie einen Monitor im Dashboard an (kostenloses Solo-Konto). Die Berechnungen sind auf der Seite Messmethodik beschrieben. UPTIMESHIELD misst keine Browser-Ladezeit und behauptet das auch nicht.