Website-Tempo messen: Warum sich der PageSpeed-Wert jedes Mal ändert.

Die Geschwindigkeit einer Website wird auf zwei getrennten Wegen gemessen: mit den Werten, die echte Besucher in den letzten 28 Tagen erlebt haben (Felddaten), und mit einem Test auf einem einzigen simulierten Gerät (Labormessung). Die Punktzahl von 0–100 in PageSpeed Insights stammt aus dem Labortest und ändert sich jedes Mal, weil Netz, Gerät und Messumgebung bei jedem Durchlauf etwas anders sind.

Dieselbe Seite im Abstand weniger Minuten zweimal zu testen und zwei verschiedene Punktzahlen zu sehen, sorgt häufig für Verwunderung. Meist bedeutet das nicht, dass sich die Website geändert hat; geändert hat sich die Messung selbst. Auch Googles eigene Dokumentation sagt, dass der Großteil der Schwankung nicht vom Messwerkzeug, sondern von der Umgebung kommt. Eine solide Lesart beginnt damit, die beiden Messwege auseinanderzuhalten.

Dieser Artikel erklärt die Messung aus der Sicht derer, die eine Website in Auftrag geben: Was sagt welches Werkzeug, wann kann man der Punktzahl trauen und wann nicht? Den technischen Unterschied der beiden Wege beschreiben wir ausführlich im Leitfaden Felddaten und Labormessung. Wenn wir die Geschwindigkeit Ihrer Website messen sollen, steht die Methode auf der Seite Website-Geschwindigkeitsoptimierung.

Wie liest man ein Ergebnis von PageSpeed Insights?

Geben Sie in PageSpeed Insights eine Adresse ein, kommt das Ergebnis in zwei Ebenen. Die obere Ebene sind Daten, die von echten Chrome-Nutzern gesammelt wurden: laut der PageSpeed-Dokumentation die LCP-, INP- und CLS-Werte aus dem vorangegangenen Erhebungszeitraum von 28 Tagen. Maßstab sind nach der Definition von web.dev 75 Prozent der Besuche; liegen LCP innerhalb von 2,5 Sekunden, INP innerhalb von 200 Millisekunden und CLS innerhalb von 0,1, besteht die Seite die Core Web Vitals. Auch der Core-Web-Vitals-Bericht in der Search Console beruht auf diesen echten Nutzerdaten.

Die untere Ebene ist der Labortest: PageSpeed öffnet die Seite mit einem Werkzeug namens Lighthouse, auf einem einzigen simulierten Gerät und in einem simulierten Netz. Die große farbige Punktzahl ist das Ergebnis dieses Tests. Nach den von Lighthouse dokumentierten Gewichten der Version 10 stammen 30 Prozent der Punktzahl aus der Total Blocking Time, 25 Prozent aus dem LCP, 25 Prozent aus der Layoutverschiebung und die übrigen 20 Prozent zu gleichen Teilen aus First Contentful Paint und Speed Index. Die Punktzahl ist also keine Zusammenfassung echter Nutzerdaten, sondern das gewichtete Zeugnis eines einzelnen Tests.

Hat die Seite keine eigenen Felddaten, greift PageSpeed auf Daten auf Ursprungsebene zurück, die alle Seiten der Website umfassen; reicht auch das nicht, erscheint die obere Ebene gar nicht. Das bedeutet nicht, dass Ihre Website schlecht ist; es bedeutet nur, dass noch nicht genügend Besuche gesammelt wurden.

Warum ändert sich der PageSpeed-Wert jedes Mal?

Die PageSpeed-Dokumentation nennt die wichtigsten Quellen der Schwankung: den momentanen Zustand des lokalen Netzes, die Hardware des Rechners, der die Messung durchführt, und andere Aufgaben, die auf demselben Rechner um Ressourcen konkurrieren. Die Lighthouse-Dokumentation ergänzt weitere: A/B-Tests auf der Website oder wechselnde Werbung, Unterschiede im Routing des Internetverkehrs, unterschiedlich leistungsfähige Testgeräte sowie Browsererweiterungen und Antivirensoftware, die Code in die Seite einschleusen. Auch die Last Ihres Servers in genau dieser Sekunde macht jeden Durchlauf etwas anders.

Die praktische Folge: Ein Unterschied von ein paar Punkten zwischen zwei Durchläufen ist keine Information, sondern Rauschen. Um zu erkennen, ob eine Änderung gewirkt hat, braucht es mehrere Durchläufe mit demselben Werkzeug, zur selben Tageszeit, mit demselben Geräteprofil, und den Blick auf den Median.

Lighthouse sagte 87, echtes Chrome 98: Woher kam der Unterschied?

Das haben wir auf unserer eigenen Website erlebt. Unsere Laborpunktzahl blieb bei 87 hängen; die Schwelle, die wir uns gesetzt hatten, war 88. Wir suchten im Code der Website, wo der eine Punkt verloren ging, und fanden nichts, weil der Verlust nicht in der Website lag. Lighthouse öffnet Chrome mit einem eigenen Starter, und in dessen Standardliste von Einstellungen wird eine Funktion von Chrome abgeschaltet. In dieser Konfiguration wurde das erste Bild spät auf dem Bildschirm dargestellt, obwohl die Seite fertig war: Auf der Live-Startseite kam der erste Paint nach 2,3–2,5 Sekunden statt nach 0,4 Sekunden. Als wir nur diese eine Zeile aus der Liste entfernten und sonst nichts anrührten, erreichte dieselbe Seite 97–98; mit der Standardeinstellung des Werkzeugs schwankte sie zwischen 78–87. Der Unterschied entstand, ohne dass sich auf der Website ein einziges Byte änderte.

Auch die zweite Hälfte der Geschichte ist lehrreich: Unsere erste Diagnose war falsch. Zuerst hielten wir den Übergangseffekt zwischen den Seiten für den Schuldigen; als eine minimale Testseite ganz ohne Übergangseffekt auf dieselbe Weise zurückgehalten wurde, war diese Lesart widerlegt. Heute berichten wir beide Zahlen gemeinsam: Verbindlich ist die Messung in der Konfiguration, die dem Chrome des Besuchers am nächsten kommt; die Standardzahl des Werkzeugs bleibt unter dem Namen „Jury-Ansicht“ im Bericht, weil ein Kunde oder eine Award-Jury höchstwahrscheinlich diese sieht. Das vollständige Experiment und die Schritte zum Nachvollziehen: Warum sagt Lighthouse 87 und echtes Chrome 98?

Der Browser, den das Messwerkzeug öffnet, ist nicht der Browser des Besuchers.

Warum reicht ein einzelner Test nicht?

Weil ein einzelner Durchlauf einen Moment misst, keine Verteilung. Der Performance-Vertrag dieser Website liest die Laborpunktzahl nicht aus einem einzelnen Durchlauf, sondern aus dem Median von mindestens fünf Durchläufen. Bei der Messung vom 23. September 2026 lag der Median der Performance-Punktzahl bei 99, der Median der Total Blocking Time bei 21 Millisekunden und die Labor-Layoutverschiebung bei 0. Der Median verhindert, dass ein einzelner glücklicher oder unglücklicher Durchlauf die Entscheidung bestimmt.

Für Ihre eigene Messung gilt dieselbe Regel: Machen Sie vor und nach einer Änderung im selben Zeitfenster je fünf Durchläufe und vergleichen Sie die beiden Mediane. Zwei Einzeldurchläufe von verschiedenen Tagen zu vergleichen, heißt, zwei verschiedene Wetterlagen zu vergleichen.

Warum hinken Felddaten 28 Tage hinterher?

Echte Nutzerdaten stammen aus dem Chrome-Bericht zur Nutzererfahrung (CrUX) und zeigen, wie web.dev erklärt, die Verteilung der letzten 28 Tage. Eine Korrektur, die Sie heute vornehmen, geht jeden Tag mit etwas mehr Gewicht in dieses Fenster ein; ihre Wirkung zeigt sich nicht an einem Tag, sondern nach und nach über Wochen. Auch die Validierung, die beginnt, wenn Sie der Search Console die Behebung eines Problems melden, ist ein Beobachtungszeitraum von 28 Tagen.

Die zweite Grenze ist die Traffic-Schwelle. Laut der Methodik-Dokumentation von Chrome muss eine Seite öffentlich zugänglich sein und genügend Besucher haben, um in diesen Daten zu erscheinen; die genaue Schwelle wird nicht veröffentlicht. Auf einer neuen oder wenig besuchten Website entstehen Felddaten womöglich nie. Dann wird die Entscheidung mit der Labormessung und mit einer eigenen Messung echter Nutzer getroffen, die sich in Ihre Seiten einbauen lässt.

Was sagt der Core-Web-Vitals-Bericht in der Search Console?

Die Search Console zeigt dieselben echten Nutzerdaten für die gesamte Website. Sie teilt nicht einzelne Adressen, sondern Gruppen von Seiten mit ähnlicher Nutzererfahrung in schlecht, verbesserungswürdig und gut ein; den Status einer Gruppe bestimmt der schlechteste der drei Werte. Mobilgeräte und Desktop werden getrennt berichtet. Dieser Bericht beantwortet die Frage „In welcher Seitenfamilie, bei welchem Wert, auf welchem Gerät hakt es?“; PageSpeed zeigt dann die Ursache für eine Seite aus dieser Familie.

Auch der Stellenwert der Geschwindigkeit in der Suche will richtig gewogen sein. Google Search Central schreibt, dass die Core Web Vitals mit dem übereinstimmen, was die zentralen Ranking-Systeme belohnen wollen; dieselbe Dokumentation sagt aber auch, dass Google versucht, die relevantesten Inhalte zu zeigen, selbst wenn die Seitennutzererfahrung schwach ist. Geschwindigkeit ersetzt keinen guten Inhalt; sie macht guten Inhalt lesbar.

Welche Fehler werden beim Messen am häufigsten gemacht?

• Auf die Desktop-Punktzahl schauen und das mobile Ergebnis übergehen — ein großer Teil der Besucher kommt über das Smartphone, und dessen Prozessor ist langsamer; Einzelheiten im Leitfaden Mobile Performance-Lücke.
• Nach einem einzigen Durchlauf entscheiden — ein Unterschied von ein paar Punkten ist Rauschen; schauen Sie auf den Median.
• In einem Browser mit installierten Erweiterungen oder bei geöffneter Administratorsitzung messen — beides fügt der Seite Last hinzu, die der Besucher nicht sieht.
• Die Punktzahl der Startseite auf die ganze Website verallgemeinern — Produkt- und Artikelseiten können ganz andere Ergebnisse liefern.
• Die Punktzahl zum Ziel machen — die Punktzahl ist eine Zusammenfassung; worauf es wirklich ankommt, ist, welcher Einzelwert fehlschlägt.
• Einen Tag nach einer Korrektur eine Verbesserung in den Felddaten erwarten — das Fenster beträgt 28 Tage.

Was sollten Sie bei einem Geschwindigkeitsbericht fragen?

Wenn Ihnen ein Geschwindigkeitsbericht vorgelegt wird, ob vom eigenen Team oder von außen, prüfen Sie, ob diese fünf Dinge klar darin stehen: ob die Zahlen aus Felddaten oder aus dem Labor stammen; bei Laborergebnissen, aus wie vielen Durchläufen der Median gebildet und mit welchem Geräteprofil gemessen wurde; welche Seiten gemessen wurden; das Datum der Messung; und ob die Ursache der Langsamkeit auf einem Browser-Trace oder auf einer Vermutung beruht. Fehlt einer dieser fünf Punkte, ist die Zahl nicht unbedingt falsch, aber man kann nicht über sie diskutieren.

Der Schritt nach dem Lesen der Messung ist die Suche nach der Ursache. Die acht häufigen Ursachen der Langsamkeit und wie man jede erkennt, haben wir im Artikel Warum lädt Ihre Website langsam zusammengestellt, die WordPress-spezifische Aufschlüsselung in WordPress-Website lädt langsam.

Wenn Sie die Geschwindigkeit Ihrer eigenen Website verbessern möchten: Unser individuelles Webdesign liefert Performance als messbares Budget aus — Ziel ist ein LCP unter 0,8 Sekunden.