PageSpeed Insights richtig lesen

PageSpeed Insights zeigt auf einer Seite zwei Messungen, die wenig miteinander zu tun haben: oben die Erfahrungen echter Chrome-Nutzer der letzten 28 Tage, unten einen einzelnen simulierten Seitenaufruf mit Lighthouse. Wer beide Teile richtig liest, versteht auch die häufigsten Widersprüche, etwa einen grünen Score bei nicht bestandener Beurteilung der Core Web Vitals oder einen Score, der bei jedem Test anders ausfällt. Dieser Ratgeber geht den Bericht von oben nach unten durch und endet mit einer Reihenfolge für die Optimierung.

Aus den Messungen von PerfDelta: Von 6.186 gemessenen Websites haben 5.935 Felddaten auf Origin-Ebene im Chrome UX Report; für die übrigen zeigt PageSpeed Insights nur den Labortest. Von den Websites mit Felddaten bestehen 48 % die Core Web Vitals. Mehr dazu im Datenblock unten.

Felddaten und Labordaten: zwei Teile eines Berichts

Der obere Teil steht unter der Überschrift Discover what your real users are experiencing (in der deutschen Oberfläche entsprechend übersetzt). Er zeigt Felddaten aus dem Chrome UX Report (CrUX). Sie stammen von Chrome-Nutzern, die der Übermittlung von Nutzungsstatistiken zugestimmt haben, und beziehen sich auf ein gleitendes Fenster von 28 Tagen. Angegeben ist jeweils das 75. Perzentil: Drei von vier Seitenaufrufen waren mindestens so schnell. Nach diesen Werten bewertet Google die Core Web Vitals in der Suche.

Der untere Teil, Diagnose performance issues, ist ein Labortest mit Lighthouse. Google lädt die Seite einmal von eigenen Servern. Mobil emuliert Lighthouse 13 ein Mittelklasse-Smartphone (Moto G Power) mit gedrosselter Verbindung („Slow 4G“), auf dem Desktop entfällt die Gerätesimulation. Pagespeed-Score, die fünf Labormetriken sowie alle Insights und Diagnosen darunter beruhen auf diesem einen Aufruf.

	Felddaten (oben)	Labordaten (unten)
Quelle	Chrome UX Report, echte Nutzer	ein Lighthouse-Lauf bei Google
Zeitraum	letzte 28 Tage, täglich aktualisiert	der Moment der Analyse
Wert	75. Perzentil aller Seitenaufrufe	Ergebnis eines Aufrufs
Metriken	LCP, INP, CLS, dazu FCP und TTFB	FCP, LCP, TBT, CLS, Speed Index
Zweck	Beurteilung der Core Web Vitals, Google-Suche	Score und Fehlersuche

Im Labor klickt und tippt niemand. Interaction to Next Paint lässt sich dort deshalb nicht messen; an seine Stelle tritt die Total Blocking Time als Maß für die Auslastung des Hauptthreads während des Ladens.

Beurteilung der Core Web Vitals: bestanden oder nicht bestanden

Die erste Zeile der Felddaten ist das Urteil, in der englischen Oberfläche Core Web Vitals Assessment: Passed oder Failed. Bestanden ist sie nur, wenn alle Core Web Vitals am 75. Perzentil im guten Bereich liegen: Largest Contentful Paint höchstens 2,5 Sekunden, Interaction to Next Paint höchstens 200 Millisekunden und Cumulative Layout Shift höchstens 0,1.

Schon eine Metrik im mittleren Bereich führt zu „nicht bestanden“, auch wenn die beiden anderen sehr gut sind. Gibt es zu wenige Interaktionen für einen INP-Wert, entscheiden LCP und CLS allein. First Contentful Paint und Time to First Byte stehen als weitere Kennzahlen daneben und zählen für das Urteil nicht.

Den Grund für ein „Failed“ zeigt der farbige Balken unter jeder Metrik. Er gibt an, welcher Anteil der Seitenaufrufe gut, verbesserungswürdig oder schlecht war. Liegt das 75. Perzentil knapp über der Schwelle und ist der Balken überwiegend grün, genügt eine kleine Verbesserung. Ein großer roter Anteil spricht für eine Ursache, die viele Besuche trifft, etwa ein zu spät entdecktes LCP-Bild auf einer häufig besuchten Vorlage. Die Grenzwerte im Einzelnen erklärt der Ratgeber Core Web Vitals.

Diese URL oder Origin: welche Felddaten Sie sehen

Über den Felddaten stehen zwei Reiter, This URL und Origin. Die URL-Ansicht zeigt Werte genau für die eingegebene Adresse. Der Origin fasst alle Seiten mit demselben Protokoll und Host zusammen, etwa alles unter https://www.beispiel.de, gewichtet nach Aufrufen. Eigene Werte bekommt eine URL nur mit genügend Chrome-Besuchen im 28-Tage-Fenster. Fehlen sie, meldet PageSpeed Insights zu wenige Daten für diese URL und bietet den Origin an.

• Im Origin dominieren die Seiten mit den meisten Aufrufen. Eine schnelle Startseite und eine langsame Produktvorlage ergeben einen Mittelwert, der zu keiner der beiden passt.
• http und https sowie die Fassung mit und ohne www sind in CrUX getrennte Origins. Prüfen Sie die Adresse, auf der Ihre Besucher tatsächlich landen.
• Hat eine URL keine eigenen Daten, führt der Core-Web-Vitals-Bericht der Search Console sie in einer Gruppe ähnlicher URLs. Eine Verbesserung an einer einzelnen Seite zeigt sich dort erst, wenn die Gruppe insgesamt besser wird.

Warum der Pagespeed-Score von den Felddaten abweicht

Ein Score von 45 neben einer bestandenen Beurteilung ist kein Fehler. Der Score entsteht aus fünf Labormetriken mit festen Gewichten: Total Blocking Time zählt 30 Prozent, LCP und CLS je 25 Prozent, FCP und Speed Index je zehn Prozent. Wie die Gewichtung im Detail wirkt, zeigt der Ratgeber zum Lighthouse Performance Score an einem Rechenbeispiel. Die Felddaten bilden dagegen Ihre tatsächlichen Besucher ab, und beides weicht aus nachvollziehbaren Gründen voneinander ab.

Das Testgerät und die Verbindung im Labor sind absichtlich langsam gewählt. Nutzen Ihre Besucher überwiegend aktuelle Smartphones im schnellen Netz, sind die Felddaten besser als der Labortest; bei einem Publikum mit einfachen Geräten kann es umgekehrt sein. Hinzu kommt der Cache: Lighthouse lädt immer ohne zwischengespeicherte Dateien, echte Besucher haben CSS, Schriften und Skripte oft schon im Browser, und Navigationen mit Zurück und Vor kommen aus dem Back-Forward-Cache ohne neue Ladezeit.

Interaktionen und spätere Layout-Verschiebungen sieht nur das Feld. Die TBT im Labor endet mit dem Laden, der INP im Feld umfasst jeden Klick und jede Eingabe des ganzen Besuchs, vom Menü über Filter bis zum Cookie-Banner. Verschiebungen beim Scrollen oder durch nachgeladene Anzeigen fließen ebenfalls nur in die Felddaten ein. Schließlich schwankt der Labortest selbst: Serverantwortzeit, Drittanbieter und Experimente ändern sich von Lauf zu Lauf. Vergleichen Sie den Median mehrerer Läufe statt einzelner Ergebnisse.

Für das Ranking zählen nur die Felddaten. Der Score ist eine Zusammenfassung eines einzelnen Ladevorgangs und eignet sich zur Diagnose, nicht als Ziel.

Insights und Diagnosen in Lighthouse 13

Seit Lighthouse 13, das PageSpeed Insights seit Oktober 2025 verwendet, ersetzen Insights die frühere Liste der Empfehlungen. Es sind dieselben Analysen, die das Performance-Panel der Chrome DevTools nach einer Aufzeichnung zeigt. Eine verbliebene Gruppe Diagnosen enthält Prüfungen ohne eigenes Insight. Beide Gruppen ändern den Score nicht unmittelbar, sie erklären die Labormetriken. Die Tabelle nennt die deutschen Bezeichnungen aus der Lighthouse-Übersetzung, die betroffene Metrik und den passenden Ratgeber.

Insight (deutsch / englisch)	Wirkt vor allem auf	Ratgeber
Anfragen zum Blockieren des Renderings / Render-blocking requests	FCP, LCP	Renderblockierende Ressourcen
LCP-Aufschlüsselung / LCP breakdown	LCP	LCP-Aufschlüsselung
LCP-Anfrageerkennung / LCP request discovery	LCP	Preconnect und Preload
Netzwerkabhängigkeitsbaum / Network dependency tree	FCP, LCP	Preconnect und Preload
Latenz der Dokumentanfrage / Document request latency	TTFB, FCP, LCP	Time to First Byte
Bildübermittlung verbessern / Improve image delivery	LCP, Seitengewicht	Bildübermittlung verbessern
Effiziente Verweildauer im Cache verwenden / Use efficient cache lifetimes	wiederholte Besuche	Browser-Caching aktivieren
Schriftart-Anzeige / Font display	FCP, CLS	font-display
Verursacher von Layout Shifts / Layout shift culprits	CLS	Verursacher von Layout Shifts
INP-Aufschlüsselung / INP breakdown	INP	INP-Aufschlüsselung
Erzwungener dynamischer Umbruch / Forced reflow	TBT, INP	Forced Reflow
DOM-Größe optimieren / Optimize DOM size	INP, TBT	DOM-Größe reduzieren
Veraltetes und dupliziertes JavaScript / Legacy and Duplicated JavaScript	TBT, Seitengewicht	Veraltetes JavaScript
Drittanbieter / 3rd parties	TBT, INP	Drittanbieter-Code
Modernes HTTP / Modern HTTP	viele kleine Dateien	meldet HTTP/1.1 erst ab sechs statischen Dateien von einem Origin
Darstellungsbereich für Mobilgeräte optimieren / Optimize viewport for mobile	INP mobil	ohne Viewport-Meta-Tag können sich Taps um bis zu 300 ms verzögern

Unter den Diagnosen führen „Reduziere nicht verwendetes JavaScript“ (Ratgeber Nicht verwendetes JavaScript entfernen), „Ausführungszeit von JavaScript reduzieren“ (JavaScript-Ausführungszeit) und „Aufwand für Hauptthread minimieren“ am häufigsten zu einer konkreten Maßnahme. Die Einsparungen neben einem Insight sind Schätzungen des Labormodells. Nutzen Sie sie zur Reihenfolge, nicht als Zusage.

Reihenfolge der Optimierung

1. Mit der durchgefallenen Metrik im mobilen Feld beginnen. Wechseln Sie auf die Ansicht für Mobilgeräte und notieren Sie, ob LCP, INP oder CLS nicht grün ist. Diese Metrik bestimmt die Arbeit, nicht die Farbe des Scores.
2. URL oder Origin prüfen. Gibt es nur Origin-Daten, testen Sie die Vorlagen mit den meisten Aufrufen, denn sie bestimmen den Wert.
3. Die Insights zur Metrik auswählen. Für LCP zuerst die LCP-Aufschlüsselung, danach LCP-Anfrageerkennung, blockierende Anfragen, Latenz der Dokumentanfrage und Bildübermittlung. Für INP die INP-Aufschlüsselung in den DevTools, dann Drittanbieter, erzwungene Umbrüche, DOM-Größe und JavaScript-Ausführung. Für CLS die Verursacher von Layout Shifts und die Schriftart-Anzeige.
4. Den größten Anteil zuerst beheben. Entfällt der größte Teil der LCP-Zeit auf die Verzögerung beim Laden der Ressource, hilft ein kleineres Bild wenig; das Bild muss früher entdeckt werden.
5. Im Labor prüfen, im Feld bestätigen. Der Labortest zeigt die Wirkung sofort, die Felddaten brauchen bis zu 28 Tage, bis alte Werte aus dem Fenster fallen.

Mehrere Seiten und Wettbewerber im Vergleich

PageSpeed Insights prüft eine URL je Test. Wie andere Vorlagen der Website abschneiden, wo Wettbewerber stehen oder ob die letzte Änderung etwas verschlechtert hat, erfordert weitere Tests. Der kostenlose Website Speed Test von PerfDelta misst mehrere Seiten einer Website mobil und auf dem Desktop in einem Durchgang, stellt Feld- und Labordaten nebeneinander, vergleicht mit bis zu zwei Wettbewerbern und verlinkt jeden Befund mit dem passenden Ratgeber. Einen reinen Felddatenvergleich von bis zu fünf Websites liefert der Core Web Vitals Benchmark.

Häufige Fragen

Warum ist die Beurteilung der Core Web Vitals nicht bestanden, obwohl der Score grün ist?

Die Beurteilung beruht auf Felddaten echter Nutzer aus 28 Tagen, der Score auf einem Labortest. Fällt der INP im Feld durch, kann der Score das nicht abbilden, weil das Labor den INP nicht misst.

Warum zeigt PageSpeed Insights keine Felddaten für meine Seite?

Der Chrome UX Report enthält nur URLs und Origins mit genügend Besuchen von Chrome-Nutzern, die Nutzungsstatistiken teilen. Neue oder selten besuchte Seiten haben keine eigenen Werte. Dann bietet PageSpeed Insights den Origin an, und fehlt auch dieser, bleibt nur der Labortest.

Warum ändert sich der Score bei jedem Test?

Jeder Test ist ein neuer Ladevorgang mit eigener Serverantwortzeit, eigenen Antworten der Drittanbieter und eigenen Netzbedingungen bei Google. Schwankungen um einige Punkte sind normal. Testen Sie drei- bis fünfmal und vergleichen Sie den Median.

Welchen Daten sollte ich vertrauen?

Für die Frage, ob die Website besteht, den Felddaten. Für die Frage, warum sie langsam ist, den Labordaten, weil sie Anfragen, Hauptthread-Arbeit und beteiligte Elemente zeigen.

Wann zeigt sich eine Verbesserung in PageSpeed Insights?

Im Labortest sofort, in den Felddaten schrittweise über bis zu 28 Tage, weil jeder neue Tag einen alten Tag im gleitenden Fenster ersetzt.