Core Web Vitals messen: PageSpeed Insights vs. CrUX vs. Lab-Daten
Core Web Vitals klingen nach einer einfachen Sache: URL eingeben, Score ablesen, fertig. Die Realität ist komplizierter. Warum zeigt PageSpeed Insights einen Score von 38, während Google Search Console dasselbe Dokument als „bestanden" markiert? Dieser Leitfaden erklärt den entscheidenden Unterschied zwischen Lab-Daten, Felddaten und wie du beides richtig interpretierst.
Drei Messmethoden — drei verschiedene Antworten
Wenn du deine Core Web Vitals prüfen willst, stehst du vor der Wahl: PageSpeed Insights, Chrome User Experience Report (CrUX), Lighthouse, Search Console oder dein eigenes Real-User-Monitoring. Jede Methode misst dasselbe — und liefert trotzdem andere Werte. Das liegt daran, dass sie grundlegend unterschiedlich arbeiten.
🔬 Lab-Daten (synthetisch) Kontrolle
Messung in einer kontrollierten Testumgebung: simulierter Browser, definierte Netzwerkbedingungen (typisch: throttled 4G mit 150ms RTT), definiertes Gerät. Tools: Lighthouse, PageSpeed Insights, WebPageTest.
Vorteil: Reproduzierbar. Du kannst Vorher/Nachher vergleichen. Funktioniert auch für neue Seiten ohne Nutzertraffic.
Nachteil: Spiegelt nicht die tatsächliche Nutzererfahrung wider. INP lässt sich in Lab-Umgebungen kaum messen (kein echter Nutzer klickt).
📊 Felddaten (real) Ranking-relevant
Echte Messungen von echten Chrome-Nutzern, gesammelt über 28 Tage. Quellen: Chrome User Experience Report (CrUX), Google Search Console, Chrome DevTools „Performance Insights".
Vorteil: Diese Daten nutzt Google für Ranking-Entscheidungen. Sie bilden die tatsächliche Nutzererfahrung ab — inklusive unterschiedlicher Geräte, Netzwerke und Nutzerverhalten.
Nachteil: Erfordert ausreichend Traffic. Neue oder wenig besuchte Seiten haben oft keine CrUX-Daten. Änderungen brauchen 28 Tage, um sich vollständig zu reflektieren.
📡 Real User Monitoring (RUM) Kontinuierlich
Eigene Erfassung der Nutzerdaten direkt im Browser via JavaScript. Tools: Web Vitals JS-Library, SpeedCurve, Datadog RUM, selbst implementiert via PerformanceObserver.
Vorteil: Vollständige Kontrolle. Segmentierbar nach Seite, Browser, Land, Gerät. Sofortige Rückmeldung bei Deployments.
Nachteil: Erfordert eigene Implementierung und Infrastruktur. Datenschutz beachten (DSGVO).
PageSpeed Insights: Was du wirklich siehst
PageSpeed Insights (PSI) ist das Tool, das die meisten SEOs zuerst öffnen. Es zeigt dir beides gleichzeitig: Lab-Daten (oben, der prominente Score von 0–100) und Felddaten aus CrUX (darunter, mit Balken für "gut", "verbesserungsbedürftig", "schlecht").
Der Performance-Score erklärt
Der Lighthouse-Score (0–100) ist eine gewichtete Summe mehrerer Lab-Metriken:
| Metrik | Gewichtung (Mobile) | Gewichtung (Desktop) |
|---|---|---|
| Total Blocking Time (TBT) | 30% | 30% |
| Largest Contentful Paint (LCP) | 25% | 25% |
| Cumulative Layout Shift (CLS) | 15% | 15% |
| First Contentful Paint (FCP) | 10% | 10% |
| Speed Index | 10% | 10% |
| Time to Interactive (TTI) | 10% | 10% |
Auffällig: INP taucht nicht im Lighthouse-Score auf — obwohl es seit März 2024 ein offizieller Core Web Vital ist. Der Grund: INP erfordert echte Nutzerinteraktionen und lässt sich in einer Lab-Umgebung kaum sinnvoll messen. Stattdessen dient Total Blocking Time (TBT) als Lab-Proxy für INP.
💡 Wichtige Erkenntnis: TBT ≠ INP
Ein niedriger TBT (unter 200ms) deutet auf einen guten INP hin, garantiert ihn aber nicht. Ein Seite mit TBT 0 kann dennoch einen schlechten INP haben, wenn ein bestimmter Event-Handler besonders schwer ist. Felddaten sind hier die einzig verlässliche Quelle.
Warum Mobile und Desktop so unterschiedlich sind
PSI testet Mobile mit einem simulierten Moto G4-ähnlichen Gerät und gedrosselter Verbindung (3.000 kbps Download, 750 kbps Upload, 150ms RTT). Desktop läuft ohne Throttling. Das erklärt, warum viele Websites Desktop-Scores von 95+ und Mobile-Scores von 40 haben — die Simulation ist bewusst pessimistisch, um schlechte Mobilgeräte abzubilden.
Chrome User Experience Report (CrUX): Googles echte Datenbasis
CrUX ist die einzige Datenquelle, die Google für seine Ranking-Entscheidungen verwendet. Es handelt sich um anonymisierte Performance-Daten, die Chrome-Nutzer freiwillig über ihre Browser-Einstellungen ("Nutzungsstatistiken und Absturzberichte senden") beisteuern.
Wie CrUX funktioniert
- 28-Tage-Fenster: CrUX aggregiert immer die letzten 28 Tage. Eine Verbesserung heute wirkt sich erst in 28 Tagen vollständig aus.
- p75-Perzentil: Google bewertet das 75. Perzentil — nicht den Median. Das bedeutet: 75% aller Messwerte liegen unter dem bewerteten Wert. Schlechte Ausreißer zählen mit.
- Mindest-Traffic: Seiten ohne ausreichend Traffic haben keine CrUX-Daten. PSI zeigt dann nur Lab-Daten.
- URL vs. Origin: CrUX erfasst Daten auf URL-Ebene und auf Domain-Ebene (Origin). Search Console zeigt URL-Gruppen.
Wo du CrUX-Daten findest
| Tool | Was du bekommst | Granularität |
|---|---|---|
| Google Search Console | CWV-Status für deine eigene Domain, gruppiert nach URL-Gruppen | Domain-eigene URLs |
| PageSpeed Insights (oben) | CrUX für die eingegebene URL + Origin | Einzelne URL |
| CrUX Dashboard (Looker Studio) | Historische CrUX-Trends für deine Domain | Origin-Ebene |
| CrUX API | Programmatischer Zugriff auf CrUX-Daten | URL und Origin |
| BigQuery (CrUX Public Dataset) | Vollständige CrUX-Daten für alle öffentlichen URLs | Beliebig |
Das Paradox: Search Console sagt "bestanden", PSI zeigt Score 38
Dieses scheinbare Widerspruch verwirrt viele SEOs. Die Auflösung ist einfach:
- Search Console nutzt Felddaten (CrUX) und bewertet nach den binären CWV-Schwellenwerten (gut/braucht Verbesserung/schlecht). Wenn LCP, CLS und INP alle im "gut"-Bereich liegen, gilt die Seite als "bestanden".
- PSI-Score ist kein CWV-Score. Der Lighthouse-Score von 38 misst 6+ Metriken mit spezifischer Gewichtung — inklusive TBT, Speed Index und TTI, die nicht in die CWV-Bewertung einfließen.
Eine Seite kann die Core Web Vitals bestehen (alle drei CWV gut) und trotzdem einen PSI-Score von 50 haben — weil TBT oder Speed Index schlecht sind. Umgekehrt kann ein PSI-Score von 90 koexistieren mit einem schlechten INP-Feldwert.
🎯 Praxis-Tipp: Was du priorisieren solltest
Fokussiere dich zuerst auf die Felddaten in der Google Search Console. Wenn deine CWV-Felddaten "gut" sind, hat das direkte Ranking-Relevanz. Lab-Daten (PSI-Score) sind wichtig für die Diagnose — aber nicht direkt für das Ranking. Optimiere zuerst für CrUX, dann für Lighthouse.
Welches Tool für welche Aufgabe?
| Aufgabe | Empfohlenes Tool | Warum |
|---|---|---|
| Ranking-Status prüfen | Google Search Console | Zeigt CrUX-basierte Bewertung, die Google für Ranking nutzt |
| Neue Seite testen (kein Traffic) | PageSpeed Insights / Lighthouse | Keine CrUX-Daten verfügbar → Lab-Daten als Proxy |
| Deployment-Impact messen | RUM + WebPageTest | Sofortige Rückmeldung, kein 28-Tage-Delay |
| LCP-Ursache debuggen | Chrome DevTools + Lighthouse | Zeigt Wasserfalldiagramm und LCP-Element |
| INP-Probleme finden | Chrome DevTools → Performance-Tab | Lab-INP begrenzt messbar; Interaction-Tracing nötig |
| Wettbewerber vergleichen | CrUX API / BigQuery | Öffentliche CrUX-Daten für jede URL verfügbar |
| Trendanalyse über Zeit | CrUX Dashboard (Looker Studio) | Historische Entwicklung auf Origin-Ebene |
Core Web Vitals im Kontext des Rankings
Seit dem Page Experience Update 2021 fließen Core Web Vitals als Ranking-Faktor in Google ein. Wichtig zu verstehen: CWV sind kein dominanter Faktor — Content-Relevanz, Autorität und Backlinks bleiben wichtiger. Aber bei vergleichbaren Seiten kann eine gute CWV-Performance den entscheidenden Unterschied machen.
Google kommuniziert das klar: "Page experience is one of many factors our systems take into account. A page with the best page experience might not rank highest if the page with the best content has a poor page experience." Übersetzt: Inhaltsqualität schlägt Performance — aber Performance ist kein Bonus mehr, sondern Basis.
Was "bestanden" wirklich bedeutet
Googles CWV-Bewertung gilt auf Seitengruppen-Ebene in der Search Console. Eine URL-Gruppe "besteht", wenn mindestens 75% der gemessenen Nutzer ein "gutes" Erlebnis haben — für alle drei Metriken (LCP ≤ 2,5s, CLS ≤ 0,1, INP ≤ 200ms). Das p75-Kriterium bedeutet: Du musst für 75% deiner Nutzer gut sein, nicht für alle 100%.
Core Web Vitals deiner Website sofort prüfen
Unser kostenloser Core Web Vitals Checker liefert echte Lab-Daten via PageSpeed Insights API — LCP, CLS, INP, FCP und TTFB, für Mobile und Desktop.
→ Core Web Vitals jetzt messenSchritt-für-Schritt: Richtig messen und interpretieren
- Search Console öffnen: Berichte → Core Web Vitals. Prüfe welche URL-Gruppen "schlecht" oder "verbesserungsbedürftig" sind.
- Problematische URLs identifizieren: Klicke auf eine Gruppe → Beispiel-URLs anzeigen lassen. Diese sind dein Ausgangspunkt.
- PSI für Diagnose nutzen: Gib eine konkrete Problemseite in unseren CWV-Checker oder PageSpeed Insights ein. Schau auf den LCP-Eintrag unter "Diagnostics".
- Audit in Chrome DevTools: F12 → Lighthouse → "Performance" → Report generieren. Sieh dir das Filmstrip und das LCP-Element direkt an.
- Ursache beheben: LCP oft: große unkomprimierte Bilder, kein preload, langsamer Server. CLS oft: Bilder ohne Width/Height, Ads, Webfonts. INP oft: schwere Event-Handler, langer Main-Thread.
- 28 Tage warten: Nach der Optimierung dauert es bis zu 28 Tage, bis sich Felddaten aktualisieren. Nutze Lab-Daten zur kurzfristigen Validierung.
Häufige Missverständnisse
„Mein PSI-Score ist 95 — ich bin fertig"
Nicht unbedingt. Ein hoher PSI-Score sagt nichts über INP-Felddaten aus. Prüfe immer auch die Felddaten in der Search Console, insbesondere auf INP.
„Mobile und Desktop sind gleich zu gewichten"
Google nutzt primär Mobile-Felddaten für das Ranking (Mobile-First-Indexing). Desktop-Werte sind relevant für Desktop-Nutzer deiner Seite, aber für das generelle Ranking zählt Mobile mehr.
„Einmal optimiert ist dauerhaft optimiert"
Falsch. Jedes neue JavaScript-Bundle, jede neue Ad-Integration, jedes neue Bild ohne definierten Größenangaben kann CWV verschlechtern. Integriere CWV-Monitoring in deinen Deploy-Prozess.
Fazit
Core Web Vitals zu messen bedeutet, die richtige Methode für den richtigen Zweck zu wählen. Felddaten (CrUX, Search Console) sind die Basis für Ranking-Entscheidungen und sollten deine primäre Zielgröße sein. Lab-Daten (PSI, Lighthouse) sind unverzichtbar für die Diagnose, funktionieren auch ohne Traffic und liefern sofortige Rückmeldung nach Änderungen. RUM ist der nächste Schritt für fortgeschrittene Teams, die kontinuierlich messen wollen.
Der häufigste Fehler: ausschließlich auf den PSI-Score zu optimieren und CrUX-Felddaten zu ignorieren. Google bewertet nach CrUX. Optimiere danach.
Weiterführend: Core Web Vitals verbessern: LCP, CLS, INP Schritt für Schritt · Mobile Core Web Vitals optimieren · Core Web Vitals Checker Tool