Wie messen wir die Geschwindigkeit von Webseiten?

In diesem Text erfahren Sie, wie wir die Daten zur Webgeschwindigkeit im Monitoring von pagespeed.one genau erfassen und verarbeiten.

Bevor Sie weiterlesen, vergewissern Sie sich, dass Sie die Unterschiede zwischen den verschiedenen Geschwindigkeitsmessungen (CrUX, synth und RUM) kennen und die Grundlagen unseres Geschwindigkeitsmonitorings verstanden haben.

Daten von Google-Nutzern#

Die Core Web Vitals Metriken (LCP, INP, CLS) aus dem Chrome UX Report (CrUX) sammeln wir für die Anzeige in unseren Berichten wie folgt:

• In den PLUS-Tests laden wir sie täglich in den Nachtstunden herunter und fügen sie den Berichten hinzu. Dies gilt sowohl für den Seitenbericht als auch für den Domainbericht und alle Vorkommen von CrUX-Daten in der gesamten Anwendung. Dies gilt gleichermaßen für Mobil- und Desktopgeräte.
• In den kostenlosen Tests laden wir keine Seitendaten herunter. Die Daten für Domains laden wir alle zwei Tage herunter, abwechselnd für Mobil- und Desktopgeräte.

Daten aus dem Chrome UX Report sehen Sie beispielsweise im Hauptdashboard Ihres Teams.

Daten für die monatlichen Metrikverläufe (im Domainbericht) laden wir einmal im Monat. Die Daten erscheinen jeden zweiten Mittwoch im Monat und wir verarbeiten sie innerhalb weniger Tage danach.

Metrikverlauf im Chrome UX Report nach Monaten, den wir im Domainbericht anzeigen.

Synthetische Daten#

Die Daten aus den synthetischen Lighthouse-Tests beziehen wir auf zwei Arten:

• In den PLUS-Tests betreiben wir Lighthouse auf unserer eigenen Infrastruktur und das mehrmals täglich. Näheres dazu erfahren Sie weiter unten.
• In den kostenlosen Tests laden wir weniger genaue Daten aus der PageSpeed Insights API herunter, und zwar alle zwei Tage für sowohl Desktop- als auch Mobilgeräte.

Schauen wir uns nun an, wie wir die synthetischen Messungen in den PLUS-Tests durchführen. Ab Version 4.10 können Sie auch manuelle Messungen (Beta) durchführen, mehrere Messzeiten (Beta) einstellen und der Start der Tests ist deutlich schneller — Details im Changelog zu Release 4.10.

Synthetische Daten dienen der täglichen Informationssammlung, beispielsweise für den Geschwindigkeitswächter.

Synthetische Messungen in den PLUS-Tests#

🔐 Diese Art der Messung führen wir in den PLUS-Tests durch.

Auf Grundlage unserer Erfahrungen mit anderen Tools während der Geschwindigkeitsberatung für Webseiten und vieler Experimente, die wir während der Entwicklung unseres Monitorings durchgeführt haben, sind wir zu folgendem Testverfahren für jede URL gekommen.

Wir testen in den Nachtstunden, fünfmal hintereinander und führen dies einmal täglich durch.

Nachtstunden#

Für die kurzfristige (Tage) und langfristige (Monate) Datensammlung der Metriken Core Web Vitals halten wir Nachtzeiten für eine Best-Practice.

Nachts sind Ihre Server weniger belastet, wir können sie in Ruhe testen und sehen dadurch den langfristigen Trend der Geschwindigkeitsentwicklung oder -verschlechterung. Die Server-Antwortzeit (Metrik TTFB) beeinflusst nämlich die Nutzer-Metriken, die wir betrachten, wie LCP oder FCP.

Wir haben die Erfahrung gemacht, dass die nächtlichen Ergebnisse viel stabiler sind und mehr über die Entwicklung der Metriken im Laufe der Zeit aussagen.

Fünfmal hintereinander#

Wir wissen, dass einmalige Tests, wie die, die wir mit PageSpeed Insights in unseren kostenlosen Tests durchführen, ungenaue Ergebnisse zeigen können.

Durch Experimente haben wir festgestellt, dass fünf Tests erforderlich sind, um die meisten Ungenauigkeiten zu beseitigen und maximale Stabilität der Zahlen zu erreichen. Die Tests finden im Abstand von wenigen Minuten statt, die genauen Zeiten sehen Sie immer im Detail des Lighthouse-Tests.

Einmal täglich#

Jede URL testen wir standardmäßig im Abstand von wenigen Minuten und starten diese Tests immer einmal täglich, immer nachts.

Warum testen wir so „wenig“?#

Gelegentlich erhalten wir die Frage, warum die Tests nur in einem kurzen täglichen Zeitfenster stattfinden. Warum testen wir nicht synthetisch jede Minute?

Hier ist es ziemlich wichtig zu klären, dass unser Monitoring dazu dient, Nutzermetriken wie Core Web Vitals und andere zu testen. Es geht also nicht um die Überwachung der Serververfügbarkeit oder der Serverbelastung. Dafür gibt es andere Tools wie Uptimerobot.com oder Updown.io.

Synthetische Messungen sollten zudem keine Nutzerdaten ersetzen, die dazu dienen, genaue Informationen über die Webleistung zu sammeln, nicht nur über alle Tageszeiten hinweg, sondern auch über alle weiteren Nutzersegmente hinweg.

Für die Beobachtung von Änderungen bei den Nutzern sammeln wir Daten aus dem Chrome UX Report und bei größeren Websites setzen wir SpeedCurve RUM ein.

Worauf testen wir und wie ist die Messung eingestellt?#

Das Testen erfolgt auf der europäischen Infrastruktur von Amazon Web Services (AWS), derzeit aus Frankfurt am Main.

Die Testmaschinen wählen wir sorgfältig aus, um Schwankungen so gering wie möglich zu halten, insbesondere bei Javascript-Metriken wie Total Blocking Time (TBT).

Trotzdem kann es natürlich gelegentlich zu Schwankungen kommen, die durch die Messinfrastruktur verursacht werden. In solchen Fällen informieren wir darüber und fügen den Grafiken automatische Notizen hinzu.

Und wie ist die Messung eingestellt? Seit Oktober 2024 ist die Verlangsamung beider Messungen wie folgt:

Gerät	Download	Upload	RTT (round-trip time)
Mobil	1,6 Mbit/s	0,75 Mbit/s	100 ms
Desktop	10 Mbit/s	10 Mbit/s	40 ms

Welche URL testen wir tatsächlich?#

Die in den Testeinstellungen eingegebene URL muss nicht mit der URL übereinstimmen, die wir letztendlich testen. Diese URL nennen wir finale URL.

Warum unterscheidet sie sich? Webserver führen häufig Umleitungen durch – zum Beispiel von example.com zu www.example.com, von HTTP zu HTTPS oder fügen am Ende der Adresse einen Schrägstrich hinzu. Unser Tool (wir nennen es „Redirector“, mehr im Changelog zu Release 4.10) durchläuft diese Umleitungen und findet die tatsächliche finale URL, auf der dann der Test durchgeführt wird.

Wo finden Sie die finale URL? In der Anwendung sehen Sie sie in Tooltips über den Symbolen der Metriken in Tabellen (unter der Beschriftung „Getestete URL“) und im Detail des Testlaufs.

Warum kann sich die finale URL zwischen synthetischen und Nutzerdaten unterscheiden? Jede Datenquelle gibt die finale URL auf ihre Weise zurück:

• Lighthouse (synth)
  gibt die URL zurück, an der der Test tatsächlich endete, nach allen Umleitungen. Diese URL entspricht in der Regel der Ausgabe des Redirectors, einschließlich eventueller Query-Parameter.
• CrUX API (Nutzerdaten)
  gibt die URL zurück, für die es reale Nutzerdaten hat. Dabei können einige Query-Parameter entfernt werden, wenn nicht genügend Daten dafür vorhanden sind, und es führt eigene Umleitungen durch.

Daher kann es sein, dass Sie in der Tabelle der Nutzerdaten (CrUX) eine andere getestete URL sehen als in der Tabelle der synthetischen Messungen (Lighthouse).

Wie lassen Sie unseren Bot auf Ihre Webseite?#

Es kann vorkommen, dass Sie eine unfertige Version Ihrer Webseite oder eine Vorschau (z. B. Beta, Test, Staging, Pre-Production), die hinter einer Form von Schutz verborgen ist, testen möchten.

Manchmal gelingt das Geschwindigkeitstesten jedoch auch auf Produktionswebseiten nicht. Unser Testroboter kann nämlich „Opfer“ der Bot-Blockierung in Ihrer Infrastruktur werden.

Es ist jedoch möglich, unseren Roboter auf eine der folgenden Arten zuzulassen:

• Erkennen Sie den User-Agent-String. Unser Roboter enthält Wörter wie PageSpeed.ONE oder Chrome-Lighthouse.
• Erkennen Sie die IP-Adresse. Unser Roboter kommt von der Adresse 18.192.177.19.

Wenn Ihre Infrastruktur eine WAF (Web Application Firewall) verwendet, muss eine neue Regel hinzugefügt werden, die das Blockieren im Falle des Zugriffs von unserer IP-Adresse, siehe oben, überspringt. Dies kann beispielsweise bei Cloudflare, Azure oder anderen Anbietern passieren.

Wie misst man Webseiten mit HTTP-Authentifizierung?#

HTTP-Authentifizierung (oft in Form von HTTP Basic Auth) ist eine einfache Möglichkeit, eine Webseite zu schützen, die einen Benutzernamen und ein Passwort bei der Seitenladung erfordert.

Sie wird hauptsächlich für Staging- oder Entwicklungsversionen von Webseiten verwendet und kann auf dieselbe Weise beim synthetischen Testen im Monitoring PLUS genutzt werden.

Beachten Sie jedoch, dass eine Webseite hinter einem Passwort langsamer sein kann. Aufgrund der Verwendung von HTTP-Auth können Sie um Dutzende Prozent schlechtere Metriken für TTFB, FCP oder LCP sehen. Wir erklären, warum.

Wie man HTTP Basic Auth in der Messung einstellt#

Unsere Tests kommen mit HTTP-Authentifizierung klar – geben Sie einfach die URL mit den Anmeldedaten im Tester ein. Der Zugriff erfolgt über Standard-Basic-Auth, genau wie ein normaler Browser sich anmelden würde.

Fügen Sie die URLs mit Anmeldedaten in die Testeinstellungen ein:

https://benutzername:passwort@test.example.com/url

Einfluss auf die Messergebnisse#

Webseiten, die in Staging-Umgebungen laufen, haben oft eine instabile Serverantwort. Sie laufen in der Regel ohne Cache, ohne CDN, manchmal im Debug-Modus. Das Ergebnis ist eine Verlangsamung aller Ladegeschwindigkeitsmetriken (TTFB, FCP, LCP).

Die HTTP-Authentifizierung allein fügt nach unseren Messungen weitere ca. 450–500 ms Verzögerung hinzu, ebenfalls mit Einfluss auf die Ladegeschwindigkeitsmetriken.

Den Einfluss der HTTP-Authentifizierung können Sie in den HAR- oder Tracy-Dateien im Detail des Testlaufs in den Phasen Stalled oder Request sent sehen.

Wie man genauer auf einem Staging-Server misst#

Wenn Sie eine Staging- oder nicht öffentliche Version ohne Verzerrung messen müssen:

• Verwenden Sie eine Backdoor basierend auf der IP-Adresse, siehe oben, oder dem User-Agent-String, siehe oben.
• Stellen Sie eine Ausnahme für unseren Bot ein, siehe oben.

Auf diese Weise erhalten Sie sauberere Daten, die nicht durch HTTP-Authentifizierung verzögert werden.

---

Probieren Sie unser PLUS-Geschwindigkeitsmonitoring aus.