Eine gute Antwortzeit für eine Website, gemessen als Time to First Byte einer HTML-Seite, liegt grob unter 200 Millisekunden für eine gecachte Seite und unter 600 Millisekunden für eine dynamische. Die web.dev-Empfehlungen von Google stufen eine Time to First Byte von 0,8 Sekunden oder weniger als gut ein. Ab etwa einer Sekunde spüren Besucher die Wartezeit, bevor überhaupt etwas auf dem Bildschirm erscheint. Diese Zahlen sind Faustregeln, keine harten Grenzen: Wichtiger ist, dass Ihre Antwortzeit stabil ist und Sie merken, wenn sie sich verschiebt.
Dieser Leitfaden erklärt, was die Antwortzeit misst, wie sie sich von der Ladezeit einer Seite unterscheidet, warum Ihr Monitor und Ihr Browser unterschiedliche Werte anzeigen und wie Sie sie verfolgen, damit Verlangsamungen behoben werden, bevor sie zu Ausfällen werden.
Antwortzeit ist nicht Ladezeit
Die beiden Begriffe werden oft verwechselt, messen aber Unterschiedliches.
Die Antwortzeit ist die Zeit, die der Server braucht, um eine einzelne Anfrage zu beantworten. Bei einem Monitor ist damit meist die Zeit vom Senden der Anfrage bis zum Eintreffen der Antwort gemeint.
Die Ladezeit ist die Zeit, die der Browser braucht, um eine nutzbare Seite anzuzeigen. Sie umfasst die Antwortzeit des HTML-Dokuments plus das Herunterladen und Ausführen von CSS, JavaScript, Schriften und Bildern, oft Dutzende weitere Anfragen.
Eine Seite kann eine schnelle Antwortzeit und trotzdem eine langsame Ladezeit haben, etwa wenn der Server in 150 Millisekunden antwortet, die Seite danach aber drei Megabyte JavaScript lädt. Unsere Tipps für eine schneller ladende Website behandeln diese Frontend-Seite. Auch der umgekehrte Fall kommt vor: Ein gut optimiertes Frontend kann einen Server nicht verbergen, der vier Sekunden für das HTML braucht. Die Antwortzeit ist der Teil, den Ihr Server und Ihr Hosting bestimmen. Die Ladezeit ist der Teil, den Ihr Frontend bestimmt. Beides zählt, und beides braucht andere Lösungen. Für die Ladezeit führt das Page-Speed-Monitoring von Uptimecheck jeden Tag Google Lighthouse für Mobilgeräte und Desktop aus und alarmiert Sie, wenn der mobile Score einer Seite unter Ihren Grenzwert fällt.
Woraus sich die Time to First Byte zusammensetzt
Die Time to First Byte, kurz TTFB, ist die Zeit vom Beginn der Anfrage bis zum Eintreffen des ersten Bytes der Antwort. Sie besteht aus mehreren Schritten:
DNS-Lookup: den Hostnamen in eine IP-Adresse auflösen.
TCP-Verbindung: der Hin- und Rückweg, um eine Verbindung aufzubauen.
TLS-Handshake: die Verschlüsselung für HTTPS aushandeln.
Verarbeitung auf dem Server: Die Anwendung läuft, fragt die Datenbank ab und erstellt die Antwort.
Erstes Byte in der Leitung: Der Anfang der Antwort ist auf dem Rückweg.
Mit curl sehen Sie jeden Schritt für Ihre eigene Website:
curl -o /dev/null -s -w „dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n“ https://northwind.shop/
Die Werte sind kumulativ. Liegt tls bei 0,12 Sekunden und ttfb bei 0,95 Sekunden, hat der Server etwa 0,8 Sekunden gebraucht, um die Seite zu erstellen. An dieser Zahl sollten Sie arbeiten. Sind die Schritte DNS oder Connect groß, liegt das Problem an der Entfernung, am Netzwerk oder am DNS und nicht an Ihrer Anwendung. Uptimecheck teilt die Antwortzeit jeder Prüfung in dieselben Phasen auf: DNS, Verbindung, TLS, Server und Download.
Warum Monitore und Browser unterschiedliche Werte zeigen
Es ist normal, dass Ihr Uptime-Monitor, die Entwicklertools Ihres Browsers und ein Performance-Testtool für dieselbe Seite unterschiedliche Antwortzeiten anzeigen. Die häufigsten Gründe:
Standort. Eine Prüfung von einem anderen Kontinent fügt jedem der Schritte oben weitere Hin- und Rückwege hinzu. Ein Server in Stockholm antwortet einem Besucher in Stockholm schneller als einer Prüfung von der US-Ostküste.
Wiederverwendung von Verbindungen. Ihr Browser hält Verbindungen offen und nutzt sie erneut. Eine Monitoring-Prüfung baut oft jedes Mal eine neue Verbindung auf und zahlt deshalb bei jeder Anfrage für DNS, TCP und TLS.
Caching. Ihr Browser hat die Seite oder Teile davon womöglich im Cache, und ein CDN liefert manchen Regionen eine gecachte Kopie aus und anderen nicht.
Was gemessen wird. Ein Tool meldet die TTFB, ein anderes die Gesamtzeit für das Herunterladen der vollständigen Antwort, ein drittes die gesamte Ladezeit der Seite.
Cookies und Logins. Angemeldete Benutzer umgehen oft den Seiten-Cache, ihre Antworten sind daher langsamer als bei einer anonymen Prüfung.
Keiner dieser Gründe macht einen Wert falsch. Entscheidend ist, Gleiches mit Gleichem zu vergleichen: dieselbe Prüfung vom selben Standort über die Zeit. Ein Monitor, der jede Minute dieselbe Anfrage misst, liefert Ihnen eine konsistente Baseline, und Abweichungen von dieser Baseline sind das, worauf Sie reagieren.
Sinnvolle Zielwerte als Faustregeln
Die Bereiche unten sind Faustregeln für die Serverantwort einer HTML-Seite oder eines API-Aufrufs, gemessen von einem Standort einigermaßen nah an Ihrem Server. Sie sind ein Ausgangspunkt für Ihre eigene Baseline, kein Standard.
Art der AntwortKomfortabelLohnt eine UntersuchungGecachte Seite oder statische Datei über CDNunter 100–200 msüber 400 msDynamische Seite (CMS, Shop, App)unter 300–600 msüber 1 sEinfacher lesender API-Endpunktunter 100–300 msüber 800 msSuche, Berichte, aufwendige Abfragenunter 1–2 süber 3 s
Zwei Hinweise zum Lesen der Tabelle. Erstens kommt die Netzwerkentfernung hinzu: Eine Prüfung von einem anderen Kontinent kann einige hundert Millisekunden obendrauf legen, und das kann Ihre Anwendung nicht beheben. Zweitens ist die wichtigste Spalte die, die Sie selbst festlegen. Antwortet Ihr Checkout normalerweise in 350 ms und heute in 900 ms, hat sich etwas geändert, auch wenn 900 ms auf dem Papier noch akzeptabel aussehen.
Was Antwortzeiten ausbremst
Steigt die Antwortzeit, ist die Ursache fast immer eine der folgenden:
Langsame Datenbankabfragen: ein fehlender Index, eine Abfrage, die mit der Tabellengröße wächst, oder ein Plugin, das Dutzende Abfragen pro Seite ausführt.
Kein Seiten- oder Objekt-Cache: Jede Anfrage baut dieselbe Seite von Grund auf neu.
Externe Aufrufe während der Anfrage: Zahlungs-, Versand-, Such- oder Analytics-APIs, die synchron aufgerufen werden, während der Besucher wartet.
Zu wenige Worker: Anfragen stauen sich, wenn alle Worker von PHP-FPM, Node oder dem Anwendungsserver beschäftigt sind.
Knappe Ressourcen: CPU am Limit, Arbeitsspeicher im Swap oder Festplatten-I/O, das durch Backups oder Log-Schreibvorgänge ausgelastet ist.
Kaltstarts: Serverless-Funktionen und Container, die auf null skaliert wurden, brauchen Zeit, um die erste Anfrage zu starten.
Entfernung: Besucher weit weg vom Server, ohne CDN dazwischen.
Warteschlangen sind der Grund, warum die Antwortzeit für die Verfügbarkeit zählt. Werden Antworten langsamer, belegt jede Anfrage einen Worker länger, der Pool füllt sich, und neue Anfragen warten oder werden abgewiesen. Eine Verlangsamung, die mit einer zusätzlichen halben Sekunde beginnt, kann bei der nächsten Lastspitze als 503 Service Unavailable enden.
Den Trend verfolgen, nicht eine einzelne Prüfung
Eine einzelne langsame Prüfung sagt wenig. Ein Netzwerkaussetzer, eine Pause durch die Garbage Collection oder ein Cache-Miss kann eine Anfrage verlangsamen. Dass etwas nicht stimmt, zeigt erst ein Muster:
Ein Sprung: Die Antwortzeit steigt nach einem Deployment, einem Plugin-Update oder einem Hosting-Wechsel und bleibt dort.
Ein langsamer Anstieg: Die Antwortzeit wächst jede Woche ein wenig, weil eine Tabelle oder ein Log wächst.
Ein Tagesmuster: Die Antwortzeit schießt jeden Tag zur selben Stunde hoch, oft wegen eines Backups, eines Imports oder eines Cron-Jobs, der um Ressourcen konkurriert.
Ein regionaler Unterschied: Eine Region ist langsam, eine andere nicht. Das deutet eher auf ein CDN, das Routing oder DNS hin als auf den Server.
Uptimecheck speichert die Antwortzeit jeder Prüfung für jeden Uptime-Monitor und API-Monitor, zeigt sie in Diagrammen mit Median und 95. Perzentil, und die wöchentlichen und monatlichen E-Mail-Berichte enthalten die durchschnittliche Antwortzeit neben der Uptime. Mit diesem Verlauf erkennen Sie einen Sprung noch am selben Tag statt Wochen später.
Bei anhaltender Langsamkeit alarmieren
Ein Alarm bei jeder langsamen Prüfung erzeugt Lärm, und lärmende Alarme werden ignoriert. Alarmieren Sie bei Langsamkeit, die anhält. Ein praktischer Ansatz:
Messen Sie über ein bis zwei Wochen die Baseline für jeden wichtigen Endpunkt.
Legen Sie die Warnschwelle deutlich über die normale Schwankung, zum Beispiel beim Zwei- bis Dreifachen der üblichen Antwortzeit.
Alarmieren Sie erst, wenn die Langsamkeit über mehrere aufeinanderfolgende Prüfungen oder Minuten anhält.
Schicken Sie Warnungen zur Langsamkeit in einen Team-Kanal und behalten Sie Push-Benachrichtigungen aufs Smartphone echten Ausfällen vor.
Setzen Sie für jede Prüfung ein Timeout. Eine Antwort, die 30 Sekunden dauert, ist für einen Besucher ein Fehler, egal welcher Statuscode.
In Uptimecheck legen Sie pro Monitor einen Grenzwert für langsame Antworten fest. Sind drei Prüfungen in Folge langsamer als der Grenzwert, erhalten Sie einen Langsamkeitsalarm und einen weiteren, wenn der Monitor wieder schneller wird. Langsame Zeit zählt nicht als Ausfallzeit.
Dieselben Prinzipien gelten für jeden Alarm, den Sie einrichten. Unser Leitfaden zum Reduzieren von Fehlalarmen im Uptime-Monitoring behandelt Bestätigung und Schwellenwerte ausführlicher, und Alarmschwellen für Server wählen erklärt, wie Sie Grenzwerte für CPU, Arbeitsspeicher und Festplatte setzen. Steigen die Antwortzeiten, zeigt Server-Monitoring neben Ihren Uptime-Prüfungen, ob der Server die Ursache ist. So müssen Sie nicht zwischen Datenbank, Netzwerk und Code raten.
Checkliste zur Antwortzeit
Messen Sie die TTFB Ihrer wichtigsten Seiten und Endpunkte mit curl, von nahe an Ihrem Server.
Überwachen Sie dieselben Seiten jede Minute und bewahren Sie den Verlauf auf.
Halten Sie pro Endpunkt eine Baseline fest und vergleichen Sie damit, nicht mit einem allgemeinen Wert.
Untersuchen Sie Sprünge nach Deployments und langsame Anstiege über Wochen.
Cachen Sie, was möglich ist, beheben Sie langsame Abfragen und verlagern Sie externe Aufrufe aus der Anfrage heraus.
Alarmieren Sie bei anhaltender Langsamkeit und bei Timeouts, nicht bei einzelnen langsamen Prüfungen.
Zusammenfassung
Eine gute Antwortzeit ist niedrig für ihre Art von Seite, nah an Ihrer eigenen Baseline und über die Zeit stabil. Als Faustregel gilt: einige hundert Millisekunden für dynamische Seiten und deutlich weniger für gecachte. Messen Sie sie jedes Mal auf dieselbe Weise, beobachten Sie den Trend und behandeln Sie einen anhaltenden Anstieg als Frühwarnung, denn die langsame Seite von heute ist oft der Ausfall von morgen.
Uptimecheck zeichnet bei jeder Prüfung die Antwortzeit auf, sodass Sie neben Ausfällen auch Verlangsamungen sehen. Testen Sie es 14 Tage kostenlos, ohne Kreditkarte.