Core Web Vitals selbst messen und verstehen

Die Werkzeuge im Überblick

Für die Messung stehen mehrere kostenlose Google-Werkzeuge sowie ergänzende Drittanbieter-Tools zur Verfügung. Jedes hat einen anderen Zweck:

• PageSpeed Insights (pagespeed.web.dev): der richtige Einstiegspunkt für jede Messung. Kostenlos, ohne Anmeldung, URL eingeben und sofort Ergebnis erhalten. Zeigt sowohl Labordaten als auch – wenn genug Traffic vorhanden ist – Felddaten aus dem Chrome User Experience Report (CrUX).
• Google Search Console, Bericht „Core Web Vitals": zeigt Felddaten aus echten Nutzern, gruppiert nach ähnlichen URLs (z. B. „alle Produktseiten"). Das ist die verlässlichste Quelle, weil sie reale Besucher über einen längeren Zeitraum abbildet – dauert aber Wochen, bis genug Daten für eine Aussage vorliegen.
• Chrome DevTools, Lighthouse-Tab: direkt im Browser aufrufbar (F12 → Lighthouse), liefert einen detaillierten Audit-Report mit konkreten Diagnosehinweisen, welches Element den LCP verzögert oder welches Skript den Hauptthread blockiert. Reine Labordaten, gut für Entwickler.
• Lighthouse via Kommandozeile (CLI): dieselbe Analyse wie im Browser, aber skriptbar und reproduzierbar – geeignet, um Performance-Checks automatisiert in den Deployment-Prozess einzubauen.
• WebPageTest (webpagetest.org): das fortgeschrittenste Tool der Liste. Testet von verschiedenen Standorten und Verbindungsgeschwindigkeiten aus, liefert ein Wasserfall-Diagramm, das exakt zeigt, welche Ressource wann lädt und was blockiert, sowie einen Filmstreifen des Seitenaufbaus.

Schritt für Schritt: So messen Sie richtig

1. PageSpeed Insights aufrufen (pagespeed.web.dev) und die Ziel-URL eingeben – immer für Mobile auswerten, nicht für Desktop. 2. Ergebnis lesen: Felddaten stehen oben und stammen aus echten Chrome-Nutzern, Labordaten stehen darunter und sind simuliert. Fehlen Felddaten, hat die Seite zu wenig Traffic für eine belastbare CrUX-Aussage – dann zählt zunächst das Labordatum. 3. LCP-Kandidat identifizieren: Welches Element ist das größte sichtbare – meist ein Hero-Bild oder eine große Überschrift? PageSpeed markiert es unter „Diagnose" direkt. 4. INP-Hinweise prüfen: Unter „Diagnose" zeigt PageSpeed lange Aufgaben (Long Tasks) und blockierende Skripte, die die Reaktionszeit auf Klicks verzögern. 5. CLS-Verursacher suchen: Der Bericht „Layoutverschiebungen vermeiden" listet Elemente ohne feste Breite/Höhe oder spät nachladende Inhalte einzeln auf. 6. In der Search Console nachziehen: Unter „Erfahrung → Core Web Vitals" den Trend über die letzten Wochen prüfen und URL-Gruppen mit „Schlecht" oder „Verbesserungswürdig" priorisieren. 7. Nach Optimierungen erneut messen – für belastbare Felddaten in Search Console mindestens zwei Wochen warten, weil CrUX ein rollierendes 28-Tage-Fenster nutzt.

Labordaten und Felddaten richtig einordnen

Beide Datenarten beantworten unterschiedliche Fragen, und wer sie verwechselt, optimiert am falschen Ziel vorbei. Labordaten (PageSpeed unterer Bereich, Lighthouse, WebPageTest) entstehen unter kontrollierten, immer gleichen Bedingungen – reproduzierbar, aber ohne Bezug zu echten Geräten und Netzverbindungen der tatsächlichen Besucher. Felddaten (PageSpeed oberer Bereich, Search Console, CrUX) stammen aus echten Chrome-Nutzern auf echten Geräten und Verbindungen. Google bewertet für das Ranking ausschließlich Felddaten. Labordaten bleiben trotzdem wichtig, weil sie reproduzierbar sind und sich damit gut eignen, um vor und nach einer Änderung direkt zu vergleichen – Felddaten reagieren dagegen erst mit Verzögerung von mehreren Wochen.

Werte richtig lesen

Google bewertet jede der drei Metriken in drei Stufen – gut, verbesserungswürdig, schlecht:

• LCP (Largest Contentful Paint): gut unter 2,5 Sekunden, verbesserungswürdig bis 4 Sekunden, darüber schlecht.
• INP (Interaction to Next Paint): gut unter 200 Millisekunden, verbesserungswürdig bis 500 Millisekunden, darüber schlecht.
• CLS (Cumulative Layout Shift): gut unter 0,1, verbesserungswürdig bis 0,25, darüber schlecht.

In der Search Console werden URLs nach diesen drei Stufen gruppiert dargestellt, sodass sich auf einen Blick erkennen lässt, wie viele URLs betroffen sind – nicht nur eine einzelne Testseite.

Der häufigste Messfehler: nur Desktop geprüft

Die meisten Websitebetreiber prüfen aus Gewohnheit die Desktop-Ansicht und sind mit dem Ergebnis zufrieden. Google bewertet seit dem Mobile-First-Index aber vorrangig die mobile Version. Eine Seite, die auf Desktop grün ist, kann auf Mobile trotzdem rot sein – und genau dieser mobile Wert zählt fürs Ranking. Deshalb in PageSpeed Insights und der Search Console immer zuerst den Mobile-Tab prüfen, Desktop ist zweitrangig.

Was die gemessenen Werte konkret verursacht und wie sich LCP, INP und CLS gezielt verbessern lassen, ist Thema im Artikel zur Core-Web-Vitals-Optimierung.