Was zeigt dieser Core-Web-Vitals-Bericht?
Gib eine Domain oder eine einzelne URL ein, wähle Mobile oder Desktop, und der Bericht zieht 25 Wochen field data aus Googles CrUX History API. Du bekommst ein wöchentliches Diagramm für LCP, INP und CLS, plus TTFB und FCP. Dein LCP kann nie schneller sein als einer von beiden. Das funktioniert für jede Website mit genug Chrome-Traffic – auch für die Konkurrenz.
Unter den Ladezeit-Diagrammen ist der LCP in seine vier Teile unterteilt. Weiter unten findest du CLS und INP im Zeitverlauf, danach Geräte und Navigationstypen. Diese letzten beiden und der Bild- oder Textanteil des LCP gelten für alle Geräte zusammen – egal, welchen Umschalter du gewählt hast.
So liest du die wöchentlichen CrUX-Diagramme
Ein Balken steht für eine Woche. Fahre mit der Maus darüber für den p75 dieser Woche und den Anteil guter, verbesserungswürdiger und schlechter Seitenaufrufe.
Der p75 ist der Wert, nach dem Google dich bewertet: Drei von vier Seitenaufrufen waren mindestens so gut.
- LCP ist gut bis 2,5 s und schlecht über 4 s
- INP ist gut bis 200 ms und schlecht über 500 ms
- CLS ist gut bis 0,1 und schlecht über 0,25
Du bestehst die Core Web Vitals, wenn alle drei beim p75 gut sind.
Das Badge auf jeder Metrik-Karte zeigt die Richtung einer geraden Linie über alle Wochen. Die Zusammenfassung oben vergleicht den durchschnittlichen p75 der älteren Hälfte der Wochen mit der neueren Hälfte. Der UX-Happiness-Score daneben ist mein eigener Wert: der Anteil guter Seitenaufrufe in der letzten Woche, gemittelt über LCP, INP, CLS, FCP und TTFB. Google nutzt ihn nicht, und es gibt ohnehin keinen offiziellen Core-Web-Vitals-Score.
Woher kommen die CrUX-Daten?
Von Chrome auf Android und Desktop – für Nutzer, die ihren Verlauf synchronisieren und Nutzungsstatistiken mit Google teilen. Chrome auf dem iPhone ist nicht dabei. Edge auch nicht.
Jeder wöchentliche Punkt deckt die 28 Tage davor ab, die Punkte überlappen sich also. Ein Fix, der an einem Dienstag live geht, braucht etwa vier Punkte, bis er voll sichtbar ist.
Google ergänzt jeden Montag einen neuen Punkt mit Daten bis zum Samstag davor. Am Montag ist der neueste Punkt also zwei Tage alt. Die 28 Tage zeigen, wie breit jedes Zeitfenster ist – weshalb die Verzögerung von 28 Tagen ein Mythos ist.
Das hier haben Besucher auf ihren eigenen Geräten erlebt. PageSpeed Insights lässt Lighthouse einmal von einem Google-Server aus laufen – mit einem simulierten langsamen Smartphone und Netzwerk. Lighthouse klickt nichts an und hat deshalb überhaupt keinen INP. Eine 98 in Lighthouse und eine rote INP-Linie hier können beides stimmen.
Wie unterscheidet sich das vom Core-Web-Vitals-Bericht in der Search Console?
Die Search Console liest dieselben CrUX-Daten, allerdings nur für deine eigenen Websites. Sie fasst URLs mit ähnlichem Verhalten zusammen und stuft jede Gruppe nach ihrer schlechtesten Metrik der letzten 28 Tage ein.
Die Search Console zeigt dir, welche Seitengruppe durchfällt. Die wöchentlichen Balken hier helfen dir, die Woche zu finden, in der es anfing – und von dort aus das Release.
Was du prüfen solltest, wenn eine Metrik schlechter wird
Bleib zuerst bei Mobile (der Bericht startet dort): Das ist fast immer die schlechtere der beiden Varianten. Schau dir dann den Verlauf der Linie an.
Ein Deploy zeigt sich als Anstieg über etwa vier Wochen, der danach abflacht: ein neues Theme, ein zusätzliches Tag im Tag Manager, ein Hero-Bild mit loading="lazy". Schau nach, was in der Woche live ging, in der der Anstieg begann.
Kriecht eine Linie über Monate nach oben, häufen sich meist Third-Party-Skripte an.
Öffne beim LCP das Breakdown-Diagramm und sieh nach, welcher Teil gewachsen ist. Es zählt nur Seitenaufrufe, bei denen das LCP-Element ein Bild ist. Ein höherer TTFB deutet auf den Server oder den Cache hin. Ein längeres Load Delay bedeutet, dass der Browser das LCP-Bild zu spät findet. Eine längere Load Duration bedeutet ein schwereres Bild oder eine langsame Verbindung dorthin, wo es gehostet wird. Ein wachsendes Render Delay entsteht, wenn CSS oder JavaScript den Paint aufhalten.
Was dir die CrUX-Historie nicht sagen kann
Kleine Websites bekommen keine Daten. Google braucht viele Chrome-Besuche und sagt nicht, wie viele. Seiten mit noindex oder einem Statuscode außer 200 fallen ebenfalls raus. Bleibt deine URL leer? Versuch die gesamte Domain. Der Bericht testet für dich mit und ohne www.
Selbst mit Daten bekommst du pro Metrik und Woche nur einen p75 für die gesamte Domain oder eine beliebte URL. CrUX sagt dir nicht, welches Template langsam ist, welches Element sich verschiebt oder welches Skript den Klick blockiert.
Dafür brauchst du Real User Monitoring auf deiner eigenen Website. Genau dafür habe ich CoreDash gebaut: die Seitenaufrufe auf deiner eigenen Website, verknüpft mit dem LCP-Element und der langsamen Interaktion. So siehst du innerhalb von Stunden, dass ein Fix wirkt.
