Core Web Vitals richtig lesen: Warum dein Labor-Score lügt
Ein grüner PageSpeed-Wert im Test sagt wenig über echte Nutzer. Wir zeigen, wie du LCP, INP und CLS aus Felddaten liest — und wo die typischen Fehldeutungen lauern.
Es gibt diesen Moment, in dem ein Kunde stolz einen Screenshot schickt: PageSpeed Insights, 98 von 100, alles grün. Und trotzdem klagen Besucher über eine zähe Seite. Der Widerspruch ist kein Messfehler. Er ist der Kern des Missverständnisses rund um die Core Web Vitals.
Labor ist nicht Feld
Jeder Vitals-Report besteht aus zwei Welten. Die Labordaten (Lighthouse) entstehen aus einem einzelnen, simulierten Seitenaufruf auf einer gedrosselten Referenzmaschine. Die Felddaten (CrUX, Chrome User Experience Report) sind der 28-Tage-Durchschnitt echter Chrome-Nutzer mit ihren realen Geräten, Netzen und Verbindungen.
Google bewertet für die Suche ausschließlich die Felddaten. Dein Labor-Score ist ein Diagnosewerkzeug, kein Ranking-Signal. Wer nur auf die Labor-Zahl optimiert, poliert ein Schaufenster, das niemand als Maßstab nimmt.
Die drei Metriken und was sie wirklich messen
LCP — Largest Contentful Paint. Wann erscheint das größte sichtbare Element (meist das Hero-Bild oder die Überschrift)? Ziel: unter 2,5 Sekunden beim 75. Perzentil. Der häufigste LCP-Killer ist nicht die Serverzeit, sondern ein spät geladenes Hero-Bild ohne fetchpriority="high" oder ein Render-blockierendes Stylesheet.
INP — Interaction to Next Paint. INP hat 2024 den alten FID abgelöst und misst die Reaktionszeit auf alle Interaktionen über den Seitenbesuch hinweg, nicht nur die erste. Ziel: unter 200 Millisekunden. INP ist gnadenlos gegenüber überladenem JavaScript — jedes Tracking-Skript, jeder Cookie-Banner, jede schwere Hydration kostet hier.
CLS — Cumulative Layout Shift. Wie stark springt das Layout während des Ladens? Ziel: unter 0,1. Der Klassiker: Bilder ohne width/height, nachgeladene Werbung, Webfonts, die Text verschieben.
Das 75. Perzentil verstehen
Google nimmt nicht den Durchschnitt, sondern das 75. Perzentil. Das heißt: 75 Prozent deiner Nutzer müssen die Schwelle unterschreiten. Ein guter Median rettet dich nicht, wenn das lange Ende der Verteilung — alte Smartphones, schlechtes Mobilfunknetz — versagt. Genau dort wohnt oft die Mehrheit, die du im eigenen Test nie erlebst, weil du auf einem schnellen Gerät im WLAN sitzt.
So liest du den Report richtig
- Starte immer bei den Felddaten. Kein Grund, an Lighthouse zu drehen, wenn CrUX schon grün ist.
- Prüfe nach Gerätetyp getrennt. Mobil und Desktop haben eigene Werte. Das Problem steckt fast immer mobil.
- Schau auf die Verteilung, nicht auf die eine Zahl. Der Balken „needs improvement” zeigt dir, wie nah du an der Kippe stehst.
- Nutze das Labor nur zur Ursachensuche. Lighthouse sagt dir warum es hakt — die Felddaten sagen dir ob es hakt.
Der typische Fehlschluss
Viele Teams jagen wochenlang einen Lighthouse-Punktestand von 95 auf 99 — ein Unterschied, den kein Nutzer je spürt — während die reale INP bei 340 Millisekunden liegt, weil ein Consent-Tool den Main Thread blockiert. Die Energie steckt an der falschen Stelle.
Die ehrlichere Reihenfolge: Erst fragen, welche Metrik im Feld rot ist. Dann die konkrete Ursache isolieren. Dann genau dort eingreifen. Ein entferntes 200-KB-Skript bringt oft mehr als zehn Mikro-Optimierungen am Bildformat.
Was das für die Praxis heißt
Core Web Vitals sind kein Wettbewerb um Punkte, sondern ein Stellvertreter für gefühlte Qualität. Eine Seite, die schnell erscheint, sofort reagiert und nicht herumspringt, fühlt sich wertig an — und genau das belohnt sowohl die Suchmaschine als auch der Mensch davor. Lies die Felddaten, ignoriere die Eitelkeit des Labor-Scores, und optimiere für das langsamste Viertel deiner Besucher. Dort gewinnst du echte Sichtbarkeit.