Kurz gesagt
Die Felddaten in PageSpeed Insights zeigen die Ladezeit echter Besuche der letzten 28 Tage. Ob eine Änderung wirkt, prüfen Sie mit Lighthouse unter gleichen Bedingungen und vergleichen den Median aus fünf Läufen. Eine neue Website hat anfangs oft nur Labordaten. Labordaten zeigen nicht, was Besucher tatsächlich erleben.
Das Wichtigste in Kürze
- PageSpeed Insights zeigt oben Felddaten echter Chrome-Besuche der letzten 28 Tage und darunter einen Labortest mit Lighthouse. Beide können sich widersprechen.
- Lighthouse berechnet seine Werte standardmäßig aus einem ungedrosselten Abruf. Auf datafalke.de nannte es einmal 1,36 s für das LCP, im Browser waren es 5,39 s.
- Für die Punktzahl ist der Median aus fünf Läufen laut Lighthouse-Team doppelt so stabil wie ein Lauf. Bei uns streute das LCP ohne Änderung um bis zu 366 ms.
- Läufe lokal und live sind nicht vergleichbar: Für dieselbe Seite nannte Lighthouse lokal 1.801 ms und live 1.530 ms, obwohl der lokale Server schneller war.
- Felddaten fehlen bei neuen oder wenig besuchten Websites. Google nennt keine Mindestzahl an Besuchen und nimmt keine Anträge auf Aufnahme an.
Was messen Lighthouse, PageSpeed Insights und CrUX?
Lighthouse testet eine Seite im Labor mit festgelegtem Gerät und Netz. Der Chrome UX Report (CrUX) sammelt Messwerte echter Chrome-Besuche. PageSpeed Insights zeigt beides auf einer Seite: oben die Felddaten aus CrUX, darunter einen Labortest mit Lighthouse.
Die Felddaten in PageSpeed Insights beschreiben die vergangenen 28 Tage (Google-Dokumentation zu PageSpeed Insights (externe Website)). Der Labortest ist eine Momentaufnahme. Eine einzige Ladezeit gibt es dabei nicht: Die Werkzeuge messen mehrere Kennzahlen. Am nächsten kommt dem Begriff das Largest Contentful Paint (LCP), das die Ladeleistung misst (web.dev zu Web Vitals (externe Website)). Die Tabelle zeigt, welche Frage jedes Werkzeug beantwortet. Welche Grenzwerte gelten und wie Sie die Werte verbessern, erklärt unser Beitrag zu den Core Web Vitals. Was sonst noch zur technischen Grundlage einer Website gehört, zeigt unser Leitfaden zu technischem SEO.
| Werkzeug | Daten | Beantwortet | Grenze |
|---|---|---|---|
| Lighthouse | Labortest auf Ihrem Rechner, in den Entwicklertools von Chrome oder in einer Prüfkette | Hat eine Änderung die Seite im Test schneller gemacht? | zeigt nicht, was Besucher erleben; beim üblichen Seitentest kein Interaction to Next Paint (INP) |
| PageSpeed Insights | Felddaten aus CrUX und ein Labortest auf einem Google-Rechner | Wie schnell lädt diese Adresse oder die ganze Website bei echten Chrome-Besuchen? | ohne genug Besuche keine Felddaten |
| Chrome UX Report (CrUX) | Messwerte echter Chrome-Besuche der vergangenen 28 Tage | Wie entwickeln sich die Werte bei echten Besuchen? | nennt keine Ursachen; Chrome auf dem iPhone liefert keine Daten |
Erledigt, wenn Sie für Ihre Frage das passende Werkzeug gewählt haben: Felddaten für echte Besuche, Lighthouse für die Wirkung einer Änderung.
Wie lesen Sie einen Bericht von PageSpeed Insights?
Beginnen Sie bei den Felddaten oben und prüfen Sie zuerst, ob sie für diese eine Adresse gelten oder für die ganze Website. Danach zählen die Bewertung der Core Web Vitals und die Verteilung in den Balken. Der Labortest darunter dient der Suche nach Ursachen.
Öffnen Sie PageSpeed Insights (externe Website), geben Sie eine Adresse ein und gehen Sie den Bericht in dieser Reihenfolge durch:
- Gerät wählen. Ergebnisse für Mobilgeräte und Desktop stehen getrennt. Beginnen Sie mit der Geräteart, die Ihre Kundschaft am häufigsten nutzt, im Zweifel mit Mobilgeräten.
- Geltungsbereich prüfen. Hat eine Adresse zu wenige Daten, zeigt PageSpeed Insights die Werte der ganzen Website. Dann sagt das Ergebnis wenig über Ihre langsamste Seite.
- Bewertung lesen. Bestanden ist die Prüfung, wenn alle drei Werte am 75. Perzentil gut sind. Fehlen Daten zu INP, genügen gute Werte für LCP und Cumulative Layout Shift (CLS). Fehlen Daten zu LCP oder CLS, gibt es keine Bewertung.
- Verteilung lesen. Der Wert über den Balken ist das 75. Perzentil. Steht dort für LCP 2,4 s, lag der Wert bei drei von vier Seitenaufrufen bei 2,4 s oder darunter, beim letzten Viertel darüber.
- Zeitraum beachten. Die Felddaten fassen 28 Tage zusammen und werden täglich aktualisiert. Eine Verbesserung von heute verändert sie deshalb erst nach und nach. In der Schnittstelle von CrUX steht als Zeitraum immer 28 Tage, auch wenn eine Seite erst kürzer online ist (Beschreibung der CrUX API (externe Website)).
- Labortest einordnen. Erst jetzt folgt die Punktzahl. Ab 90 gilt sie als gut. Für Mobilgeräte bildet Lighthouse in PageSpeed Insights ein Mittelklasse-Smartphone im Mobilfunknetz nach und läuft auf einem Google-Rechner in Nordamerika, Europa oder Asien. Den Standort nennt der Bericht in seinen Umgebungsangaben.
Typischer Fehler: Die Punktzahl wird zuerst gelesen, obwohl die Messwerte echter Besuche darüberstehen.
Erledigt, wenn Sie jeden Wert einer Geräteart, einem Geltungsbereich und einem Zeitraum zuordnen können. Die Angaben zu Bericht und Testumgebung stammen aus der Google-Dokumentation zu PageSpeed Insights (externe Website).
Warum weichen Lighthouse und PageSpeed Insights voneinander ab?
Lighthouse auf Ihrem Rechner und der Labortest in PageSpeed Insights nutzen zwar dasselbe Werkzeug, laufen aber auf verschiedenen Rechnern, an verschiedenen Orten und womöglich in verschiedenen Versionen. Deshalb weichen Zeiten und Punktzahl voneinander ab. Vergleichen Sie Zahlen nur innerhalb derselben Umgebung.
In der Standardeinstellung nutzt Lighthouse auf Ihrem Rechner dieselbe simulierte Drosselung wie der Labortest in PageSpeed Insights (Lighthouse-Dokumentation zur Drosselung (externe Website)). Unterschiede entstehen vor allem durch Hardware, Last auf dem Rechner und das Netz. Malware, Browser-Erweiterungen und Virenscanner beeinflussen die Messung besonders stark (Lighthouse-Dokumentation zur Streuung (externe Website)).
Damit Zahlen vergleichbar bleiben, halten Sie drei Angaben fest:
- Werkzeug und Version: Lighthouse im Browser, in einer Prüfkette oder in PageSpeed Insights, jeweils mit Versionsnummer.
- Umgebung: derselbe Rechner oder derselbe Testdienst, ein Browserprofil ohne Erweiterungen, keine andere Last auf dem Rechner.
- Seite und Stand: dieselbe Adresse mit demselben Inhalt, ohne laufende A/B-Tests oder wechselnde Werbung.
Typischer Fehler: Ein Wert aus PageSpeed Insights wird mit einem Lauf auf dem eigenen Rechner verglichen.
Erledigt, wenn zu jeder Zahl Werkzeug, Version, Umgebung und Stand der Seite notiert sind.
Wie messen Sie mit Lighthouse stabil?
Messen Sie jede Seite fünfmal und vergleichen Sie den Median, also den mittleren der fünf Werte. Für die Punktzahl ist der Median aus fünf Läufen laut Lighthouse-Team doppelt so stabil wie ein einzelner Lauf. Halten Sie Gerät, Netz, Version und Stand der Seite gleich und lassen Sie nie zwei Messungen gleichzeitig laufen.
Lighthouse-Werte schwanken auch, wenn an der Seite nichts geändert wurde. Mehrere Lighthouse-Läufe zur selben Zeit verfälschen das Ergebnis zusätzlich (Lighthouse-Dokumentation zur Streuung (externe Website)). Der Median ist hier besser als der Durchschnitt, weil ein einzelner Ausreißer ihn kaum bewegt.
Ohne Programmierkenntnisse starten Sie Lighthouse in den Entwicklertools von Chrome fünfmal hintereinander und notieren die Werte. Mit Lighthouse CI läuft die Messung per Befehl:
npx -p @lhci/cli lhci collect --url https://ihre-domain.de/ -n 5So gehen Sie vor:
- Legen Sie die Adressen fest, die Sie immer messen, zum Beispiel Startseite, wichtigste Leistungsseite und Kontakt.
- Messen Sie jede Adresse vor einer Änderung fünfmal und notieren Sie den Median je Kennzahl.
- Messen Sie nach der Änderung in derselben Umgebung erneut fünfmal.
- Werten Sie den Unterschied erst aus, wenn er größer ist als die Streuung der fünf Läufe.
Bewerten Sie den Unterschied in Millisekunden je Kennzahl. Die Punktzahl allein verbirgt, was sich geändert hat.
Typischer Fehler: Sie messen einmal vor und einmal nach der Änderung und schreiben ihr den ganzen Unterschied zu.
Erledigt, wenn Sie je Seite den Median vor und nach der Änderung kennen und der Unterschied größer ist als die Streuung der fünf Läufe.
Was zeigt ein gutes Laborergebnis nicht?
Ein gutes Laborergebnis zeigt, wie eine Seite unter den Bedingungen des Tests lädt. Wie schnell sie bei Ihren Besuchern lädt und wie sie auf Klicks reagiert, zeigt es nicht. In der Standardeinstellung berechnet Lighthouse die Zeiten außerdem aus einem Modell und kann dabei eine einzelne langsame Serverantwort übersehen.
- Reaktion auf Eingaben. Im Labor ist INP schwerer zu messen als bei echten Besuchen. Lighthouse nutzt dort ersatzweise die Total Blocking Time (TBT) als Näherung (web.dev zu TBT (externe Website)).
- Gerät und Ort. Ein Labortest läuft auf einem Gerät, in einem Netz und von einem Ort aus (web.dev zu Labor und Feld (externe Website)). Ihre Besucher nutzen viele Geräte und Netze.
- Zwischenspeicher. Labortests beginnen meist mit leerem Browser-Cache. Besucher, die wiederkommen, haben Dateien oft schon gespeichert.
- Serverantwort. Standardmäßig lädt Lighthouse die Seite ungedrosselt und berechnet daraus, wie sie auf einer langsamen Verbindung geladen hätte. Die Dokumentation nennt dafür 150 ms Latenz und 1,6 Mbit/s Datenrate und weist auf Ungenauigkeiten in Sonderfällen hin.
Für die Serverzeit nimmt das Modell den Median der beobachteten Antwortzeiten aller Anfragen an denselben Server, in der von uns eingesetzten Version (Quelltext für Lighthouse 12.6.1 (externe Website)) ebenso wie in der neuesten (Quelltext für Lighthouse 13.6.0 (externe Website)). Eine einzelne sehr langsame Antwort kann darin verschwinden. Wie stark das wirken kann, zeigen unsere Messreihen von datafalke.de.
Den grundsätzlichen Unterschied zwischen Labor- und Felddaten erklärt unser Beitrag zu den Core Web Vitals im Abschnitt Was unterscheidet Labordaten von Felddaten?
Erledigt, wenn Sie einen guten Laborwert als Hinweis nutzen und für echte Besuche Felddaten heranziehen.
Was tun Sie, wenn Felddaten fehlen?
Prüfen Sie, ob Ihre Seiten öffentlich und indexierbar sind, messen Sie weiter im Labor und ergänzen Sie bei Bedarf eine eigene Messung echter Besuche. Felddaten fehlen, wenn der Chrome UX Report zu wenige Besuche für eine Adresse oder Website hat. Die Mindestzahl nennt Google nicht, und einen Antrag auf Aufnahme gibt es nicht.
PageSpeed Insights zeigt bei zu wenig Daten für eine Adresse die Werte der ganzen Website. Reichen auch diese nicht, zeigt es keine Felddaten (Google-Dokumentation zu PageSpeed Insights (externe Website)). In der Search Console heißt der Zustand „Keine Daten verfügbar“: Die Property ist neu oder im Chrome UX Report liegen zu wenige Daten vor (Search Console-Hilfe zum Core Web Vitals-Bericht (externe Website)).
Fehlende Felddaten sind keine schlechte Bewertung. Google beschreibt in seiner Dokumentation nicht, wie es solche Seiten im Ranking behandelt.
So gehen Sie vor:
- Bedingungen prüfen. Für den Chrome UX Report muss eine Seite öffentlich auffindbar sein, mit Status 200 antworten und darf kein noindex tragen (CrUX-Methodik (externe Website)). Fehlt Ihre Website bei Google, hilft unser Ratgeber Warum wird meine Website nicht bei Google angezeigt?
- Im Labor weitermessen. Nehmen Sie bei jeder Änderung den Median aus fünf Läufen für Ihre wichtigsten Seiten.
- Bei Bedarf selbst messen. Die Bibliothek web-vitals (externe Website) von Google erfasst Web-Vitals-Werte im Browser Ihrer Besucher. Sie brauchen dafür ein Skript auf der Seite und eine Stelle, an der die Werte ankommen. Klären Sie vorher mit Ihrer Datenschutzberatung, ob und wie Sie das einsetzen dürfen.
- Abwarten. Einen Termin nennt Google nicht. Erreicht die Website die Mindestzahl an Besuchen, nimmt der Chrome UX Report sie von selbst auf.
Typischer Fehler: Ein Laborwert steht im Bericht an die Geschäftsführung, als wäre er die Ladezeit echter Besuche.
Erledigt, wenn Ihre Seiten die Bedingungen erfüllen und Sie für die wichtigsten Seiten einen Laborwert mit Datum haben.
Welche Fehlschlüsse sollten Sie vermeiden?
Messwerte täuschen vor allem dann, wenn Sie Zahlen aus verschiedenen Umgebungen gleichsetzen oder einen einzelnen Lauf als Ergebnis nehmen. Eine Punktzahl sagt außerdem wenig über echte Besuche. Fehlende Felddaten bedeuten nur, dass Google noch zu wenige Besuche ausgewertet hat.
Die Zahlen in der Spalte „Quellen“ sind die Nummern der Quellenliste am Ende des Beitrags.
| Fehlschluss | Was gilt | Quellen |
|---|---|---|
| „100 Punkte heißen, die Website ist schnell.“ | Die Punktzahl bewertet einen Labortest. Ab 90 gilt sie als gut. Echte Besuche bildet sie nicht ab. | 1 |
| „Die Punktzahl ist gefallen, also ist die Seite schlechter geworden.“ | Werte schwanken auch ohne Änderung an der Seite. Vergleichen Sie den Median aus fünf Läufen. | 5 |
| „Die Felddaten bewegen sich nicht, die Änderung hat nichts gebracht.“ | Felddaten fassen 28 Tage zusammen. Neue Werte verdrängen alte erst nach und nach. | 1, 3 |
| „Lokal ist die Seite schnell, also ist sie es auch live.“ | Server und Netz unterscheiden sich. Messen Sie die Live-Website. | 5 |
| „Keine Felddaten bedeuten eine schlechte Bewertung.“ | Die Website hat zu wenige Besuche. Eine Bewertung ist das nicht. | 1, 9 |
| „Der Wert gilt für genau diese Seite.“ | Bei zu wenig Daten für eine Adresse zeigt PageSpeed Insights die ganze Website. | 1 |
| „Die Felddaten zeigen alle meine Besucher.“ | Sie stammen nur aus Chrome, und Chrome auf dem iPhone fehlt. | 9 |
Dass eine höhere Punktzahl zu einem besseren Ranking führt, sagt Google nicht. Mehr dazu steht im Beitrag zu den Core Web Vitals. Wann Sie nach einem Relaunch nachmessen, zeigt unsere Relaunch-Checkliste.
Erledigt, wenn Sie vor jedem Vergleich prüfen, ob beide Zahlen aus derselben Umgebung stammen.
Aus der Praxis: Was unsere Messreihen zeigen und was nicht
Am 08.11.2026 haben wir datafalke.de mit Lighthouse gegen die Live-Website gemessen: alle 98 Adressen je einmal, zehn feste Messseiten je fünfmal. Alle Adressen hielten die Grenzen unserer Prüfkette ein, bei den zehn Messseiten im Median aus fünf Läufen. Im Einzellauf lag die Leistung je Adresse bei 98 bis 100 Punkten, das LCP bei 1,06 bis 1,68 s und das CLS bei höchstens 0,040. Das sind Laborwerte. Felddaten liegen uns für die Website noch nicht vor.
Messung vom · Lighthouse 12.6.1 in Chrome 156, mobil, simulierte Drosselung, Arbeitsrechner gegen die Live-Website, zehn Seiten mit je fünf Läufen
In der Nacht zum 09.11.2026 lief dieselbe Prüfung als Teil unserer Prüfkette gegen einen wenige Stunden jüngeren Stand auf dem Arbeitsrechner. Die letzte Spalte zeigt diese Werte.
| Seite | Leistung live | LCP live, Median | Spanne live | LCP lokal, Median |
|---|---|---|---|---|
| / | 100 | 1.502 | 1.355–1.506 | 1.501 |
| /en/ | 100 | 1.505 | 1.358–1.530 | 1.501 |
| /kontakt/ | 100 | 1.502 | 1.206–1.513 | 1.501 |
| /leistungen/ | 100 | 1.207 | 1.205–1.357 | 1.501 |
| /leistungen/geo-optimierung/ | 100 | 1.508 | 1.433–1.654 | 1.651 |
| /leistungen/softwareentwicklung/ | 100 | 1.429 | 1.380–1.455 | 1.501 |
| /leistungen/website-erstellen-lassen/ | 99 | 1.654 | 1.356–1.680 | 1.651 |
| /methode/ | 99 | 1.656 | 1.293–1.659 | 1.651 |
| /wissen/generative-engine-optimization/ | 100 | 1.530 | 1.358–1.586 | 1.801 |
| /en/insights/generative-engine-optimization/ | 100 | 1.576 | 1.575–1.604 | 1.801 |
Messung vom · Lighthouse 12.6.1 in Chrome 156, mobil, simulierte Drosselung, lokaler Server, zehn Seiten mit je fünf Läufen
Streuung ohne Änderung. Auf acht der zehn Seiten lagen mehr als 100 ms zwischen dem schnellsten und dem langsamsten Lauf, bei /methode/ waren es 366 ms. Geändert hatten wir in dieser Zeit nichts. Die Kontaktseite kam in einem Einzellauf auf 1.282 ms und im Median auf 1.502 ms.
Ein Lauf, der täuscht. Im dritten Lauf auf der Seite unseres Leitfadens zu Generative Engine Optimization (GEO) brauchte der Server am 08.11.2026 gegen 17:15 Uhr für die erste Antwort (Time to First Byte, TTFB) 5.161 ms, und im Browser erschien die Seite erst nach 5.391 ms. Der Bericht nannte für denselben Lauf ein LCP von 1.358 ms. Die Punktzahl fiel auf 92, weil der Speed Index auf 8.041 ms stieg. Die Ursache der langsamen Antwort ist nicht geklärt; der Rechner war ruhig. Der Median aller fünf Läufe blieb bei 1.530 ms und 100 Punkten. Das LCP allein hätte die langsame Antwort also nicht gezeigt.
| Lauf | LCP im Bericht | LCP beobachtet, ohne Drosselung | Antwort des Servers (TTFB) | Leistung |
|---|---|---|---|---|
| 1 | 1.586 | 233 | 34 | 100 |
| 2 | 1.579 | 242 | 27 | 100 |
| 3 | 1.358 | 5.391 | 5.161 | 92 |
| 4 | 1.431 | 258 | 30 | 100 |
| 5 | 1.530 | 379 | 18 | 100 |
Lokal gegen live. Der lokale Server antwortete in höchstens 4 ms, die Live-Website meist in 16 bis 52 ms. Trotzdem nannte Lighthouse für den GEO-Leitfaden lokal 1.801 ms und live 1.530 ms. Beide Läufe unterscheiden sich auch im Protokoll (lokal HTTP/1.1, live HTTP/2), in der Kompression (Brotli und gzip) und im Stand der Seiten. Welcher Unterschied den Wert bewegt, haben wir nicht einzeln geprüft. Wir vergleichen deshalb nur Läufe aus derselben Umgebung.
Stufen im Modell. Von den 50 lokalen Läufen landeten 47 bei rund 1.501, 1.651 oder 1.801 ms. Die Stufen liegen genau 150 ms auseinander, so groß ist die simulierte Latenz. Dass das Modell in diesen Stufen rechnet, ist unsere Deutung. Einzelne Unterschiede von 150 ms oder weniger sollten Sie deshalb nicht überbewerten.
Version. Unsere Prüfkette nutzt Lighthouse CI 0.15.1 mit Lighthouse 12.6.1 vom Juni 2025. Lighthouse 13.0.0 (externe Website) erschien am 10.10.2025. Lighthouse CI wechselte erst mit Lighthouse CI 0.16.0 (externe Website) vom 02.11.2026 auf die neue Hauptversion und bringt seither Lighthouse 13.6.0 (externe Website) mit. Eine Prüfkette kann also mehr als ein Jahr hinter der neuesten Hauptversion liegen. Wenn Sie Messreihen über längere Zeit führen, gehört die Version deshalb in jede Notiz.
Was die Messreihen nicht zeigen. Sie enthalten kein INP und keine Felddaten. datafalke.de ist seit dem 07.11.2026 online. Ob und wann der Chrome UX Report die Website aufnimmt, hängt von einer Besucherzahl ab, die Google nicht nennt. Bis dahin sagen unsere Zahlen nichts darüber aus, wie schnell die Seiten bei echten Besuchen laden. Felddaten veröffentlichen wir im Messprotokoll, sobald der Chrome UX Report Werte für datafalke.de ausweist.
So prüfen Sie nach: Messen Sie eine der zehn Messseiten fünfmal mit Lighthouse in den Entwicklertools von Chrome oder geben Sie die Adresse in PageSpeed Insights (externe Website) ein. Ihre Zeiten werden abweichen, weil Rechner, Netz und Version andere sind.