Core Web Vitals verständlich erklärt: LCP, INP und CLS

Wer seine Website in PageSpeed Insights prüft oder in der Google Search Console den Bericht „Core Web Vitals“ öffnet, stößt auf Abkürzungen wie LCP, INP und CLS – oft in Rot. Was steckt dahinter, wie ernst muss man die Werte nehmen, und warum zeigen zwei Werkzeuge für dieselbe Seite unterschiedliche Ergebnisse?

Dieser Artikel erklärt die Messwerte selbst. Konkrete Maßnahmen für WordPress-Websites – Bilder, Caching, Schriften, Skripte – haben wir im Praxisleitfaden PageSpeed verbessern zusammengestellt.

Was sind die Core Web Vitals?

Die Core Web Vitals sind eine Auswahl von Messwerten, mit denen Google die Nutzererfahrung beim Laden und Bedienen einer Seite beschreibt. Laut web.dev, der Entwicklerplattform des Chrome-Teams, decken sie drei Bereiche ab:

• Laden: Wie schnell erscheint der wichtigste Inhalt? Gemessen mit Largest Contentful Paint (LCP).
• Interaktivität: Wie schnell reagiert die Seite, wenn jemand tippt, klickt oder etwas eingibt? Gemessen mit Interaction to Next Paint (INP).
• Visuelle Stabilität: Springen Inhalte beim Laden unerwartet hin und her? Gemessen mit Cumulative Layout Shift (CLS).

Die drei Werte sind bewusst nutzernah gewählt. Sie messen nicht, wie viele Dateien eine Seite lädt, sondern was Besucher davon spüren: das Warten auf den Inhalt, die träge Reaktion auf einen Klick, den Button, der im letzten Moment wegrutscht.

Die Grenzwerte im Überblick

Google teilt jeden Messwert in drei Stufen ein. Die Grenzwerte stammen aus dem Bericht „Core Web Vitals“ der Search Console und den Erläuterungen auf web.dev:

Eine Seite besteht die Bewertung, wenn alle drei Werte am 75. Perzentil im grünen Bereich liegen. Das heißt: Mindestens drei von vier Seitenaufrufen müssen die Grenze einhalten. Die Bewertung erfolgt getrennt für Mobilgeräte und Desktop – eine Seite kann am Rechner gut und auf dem Smartphone schlecht abschneiden.

LCP: Wann ist der wichtigste Inhalt da?

Largest Contentful Paint misst laut web.dev die Zeit vom Aufruf der Seite bis zur Darstellung des größten Bildes, Textblocks oder Videos im sichtbaren Bereich. Auf typischen Unternehmensseiten ist das meist das große Kopfbild, ein Hintergrundbild im oberen Bereich oder die Hauptüberschrift.

Woraus sich der LCP zusammensetzt

Google zerlegt den LCP in vier Abschnitte. Diese Aufteilung hilft bei der Ursachensuche, weil jeder Abschnitt andere Ursachen hat:

1. Antwortzeit des Servers (TTFB)Bis das erste Byte der HTML-Seite ankommt. Langsames Hosting, fehlendes Caching oder Weiterleitungsketten verlängern diesen Teil.
2. LadeverzögerungBis der Browser überhaupt anfängt, das LCP-Bild zu laden. Ursache ist oft, dass das Bild erst per CSS, JavaScript oder Lazy Loading nachgeladen wird.
3. LadedauerWie lange das Bild selbst zum Herunterladen braucht – abhängig von Dateigröße und Format.
4. RenderverzögerungBis das geladene Element tatsächlich angezeigt wird, etwa weil noch Skripte oder Schriften blockieren.

Laut web.dev sollten die beiden Verzögerungsabschnitte möglichst gegen null gehen; der Großteil der Zeit sollte auf Serverantwort und eigentliches Laden entfallen.

Häufige Ursachen für schlechte LCP-Werte

• Ein unkomprimiertes, mehrere Megabyte großes Kopfbild – Hinweise zu Formaten und Größen finden Sie unter Bilder für die Website.
• Das Kopfbild wird per Lazy Loading verzögert, obwohl es sofort sichtbar ist.
• Bild-Slider, die das erste Bild erst per JavaScript einblenden.
• Günstiges Hosting ohne Seiten-Cache, das bei jedem Aufruf die Seite neu berechnet.

INP: Wie schnell reagiert die Seite?

Interaction to Next Paint misst, wie lange es dauert, bis nach einem Klick, einem Tippen auf dem Touchscreen oder einem Tastendruck die nächste sichtbare Reaktion erscheint. Scrollen, Zoomen und das Überfahren mit der Maus zählen laut web.dev nicht. Erfasst werden alle Interaktionen während eines Besuchs; gemeldet wird im Wesentlichen die langsamste.

Die drei Phasen einer Interaktion

• Eingabeverzögerung: Der Browser ist noch mit anderen Aufgaben beschäftigt, etwa mit dem Ausführen eines Tracking- oder Chat-Skripts.
• Verarbeitung: Der Code, der auf den Klick reagiert, läuft – zum Beispiel ein Menü, ein Filter oder eine Formularprüfung.
• Darstellung: Der Browser berechnet das neue Bild und zeichnet es.

Häufige Ursachen für schlechte INP-Werte

Fast immer ist zu viel JavaScript im Spiel: Seitenbaukästen mit vielen Effekten, mehrere Tracking-Dienste, Chat-Widgets, Cookie-Banner, Bewertungs-Widgets und Slider, die alle gleichzeitig laden. Auf schwächeren Smartphones fällt das deutlich stärker ins Gewicht als am Büro-Rechner. Deshalb sind INP-Probleme mobil häufiger.

CLS: Bleibt das Layout stabil?

Cumulative Layout Shift bewertet, wie stark sichtbare Elemente unerwartet verrutschen. Typisches Beispiel: Sie wollen auf „Anrufen“ tippen, darüber lädt ein Banner nach, und Sie treffen stattdessen einen anderen Link. Laut web.dev zählt dabei die stärkste Häufung von Verschiebungen innerhalb eines Zeitfensters von höchstens fünf Sekunden. Verschiebungen, die innerhalb von 500 Millisekunden nach einem Klick oder Tastendruck passieren, werden nicht gezählt – etwa wenn sich ein Akkordeon öffnet, weil jemand darauf geklickt hat.

Häufige Ursachen für schlechte CLS-Werte

• Bilder und Videos ohne angegebene Breite und Höhe, sodass der Browser keinen Platz reservieren kann.
• Webschriften, die nach dem Laden breiter oder schmaler laufen als die Ersatzschrift.
• Nachträglich eingeblendete Elemente oberhalb des Inhalts: Hinweisleisten, Cookie-Banner, Werbung, eingebettete Karten oder Bewertungs-Widgets.

Felddaten und Labordaten: Warum Werkzeuge verschiedene Werte zeigen

Die häufigste Verwirrung entsteht, weil es zwei grundverschiedene Arten von Messungen gibt.

Der bekannte Punktwert von 0 bis 100 in PageSpeed Insights stammt aus den Labordaten. Google schreibt in der Dokumentation zu PageSpeed Insights ausdrücklich, dass ein guter Laborwert nicht automatisch eine gute Erfahrung echter Nutzer bedeutet und beide Datenquellen voneinander abweichen können. Für die Bewertung zählen die Felddaten; die Labordaten sind Ihr Werkzeug zur Fehlersuche.

Wenn keine Felddaten angezeigt werden

Kleinere Websites haben oft zu wenige Chrome-Besuche, damit Google für einzelne Seiten Felddaten ausweisen kann. Die Search Console fasst ähnliche Seiten dann zu Gruppen zusammen oder greift auf Werte für die gesamte Domain zurück. Erscheint gar nichts, bleiben Ihnen die Labordaten – und der eigene Test auf echten Geräten.

Wie wichtig sind die Core Web Vitals für das Ranking?

Google schreibt in der Search-Central-Dokumentation, dass die Core Web Vitals dem entsprechen, was die zentralen Ranking-Systeme belohnen wollen, und empfiehlt Website-Betreibern ausdrücklich gute Werte. Eine Gewichtung nennt Google nicht. Aus unserer Praxis gilt: Eine inhaltlich passende, hilfreiche Seite mit mittelmäßigen Werten schlägt in der Regel eine schnelle Seite, die die Suchanfrage nicht beantwortet.

Unterschätzen sollte man die Werte trotzdem nicht. Langsame, springende Seiten kosten vor allem Anfragen: Besucher, die auf dem Smartphone warten oder danebentippen, rufen eher den nächsten Betrieb in der Trefferliste an.

So lesen Sie den Bericht in der Search Console

In der Google Search Console finden Sie unter „Nutzerfreundlichkeit“ beziehungsweise „Core Web Vitals“ je einen Bericht für Mobil und Desktop. Laut Google-Hilfe gilt:

• Seiten werden zu URL-Gruppen zusammengefasst, weil ähnliche Seiten meist dieselbe Ursache haben – etwa alle Blogartikel mit derselben Vorlage.
• Der Status einer Gruppe richtet sich nach dem schlechtesten der drei Werte.
• Beheben Sie zuerst „Schlecht“, dann „Verbesserung erforderlich“ – und innerhalb dessen die Gruppen mit den wichtigsten Seiten.
• Nach einer Korrektur starten Sie die Validierung. Google beobachtet dann 28 Tage lang die Felddaten, bevor das Problem als behoben gilt.

Wie Sie die Search Console einrichten und welche Berichte darüber hinaus wichtig sind, zeigt der Artikel Google Search Console einrichten.

Checkliste: Core Web Vitals richtig einordnen

• Ich schaue zuerst auf die Felddaten (Search Console, oberer Teil von PageSpeed Insights), nicht auf den Punktwert.
• Ich prüfe Mobil und Desktop getrennt – mobil ist meist das Problem.
• Ich weiß, welches Element auf meinen wichtigsten Seiten das LCP-Element ist.
• Das LCP-Bild ist komprimiert und wird nicht per Lazy Loading verzögert.
• Alle Bilder und eingebetteten Inhalte haben feste Abmessungen.
• Ich kenne alle externen Skripte auf der Seite und weiß, wofür jedes gebraucht wird.
• Nach jeder Korrektur starte ich die Validierung in der Search Console und warte die 28 Tage ab.

Häufige Fragen

Quellen

1. web.dev: Web Vitals – Überblick, Grenzwerte, 75. Perzentil, Werkzeuge
2. web.dev: Largest Contentful Paint (LCP)
3. web.dev: LCP optimieren – Aufteilung in vier Abschnitte
4. web.dev: Interaction to Next Paint (INP)
5. web.dev: Cumulative Layout Shift (CLS)
6. Google Search Central: Core Web Vitals und die Google Suche
7. Search Console-Hilfe: Bericht „Core Web Vitals“ – Grenzwerte, URL-Gruppen, Validierung über 28 Tage
8. PageSpeed Insights: Über PageSpeed Insights – Felddaten vs. Labordaten, Punktwert