Was sind die Core Web Vitals? LCP, INP und CLS erklärt

Google beschreibt sie als jene Untergruppe der Web Vitals, die für alle Webseiten gilt, von allen Websiteinhabern gemessen werden sollte und in allen Google-Werkzeugen ausgewiesen wird. Der Anspruch dahinter: Websitebetreiber sollen die Qualität ihrer Nutzererfahrung beurteilen können, ohne Leistungsexperten zu sein.

Die drei Messwerte und ihre Grenzwerte

Die Grenzwerte stammen aus Googles eigener Dokumentation zur Festlegung der Core-Web-Vitals-Schwellen:

Messwert	Gut	Schlecht	Perzentil
Largest Contentful Paint (LCP)	≤ 2.500 ms	> 4.000 ms	75.
Interaction to Next Paint (INP)	≤ 200 ms	> 500 ms	75.
Cumulative Layout Shift (CLS)	≤ 0,1	> 0,25	75.

Dazwischen liegt jeweils der Bereich „verbesserungswürdig".

Largest Contentful Paint

LCP gibt die Renderingzeit des größten sichtbaren Bildes, Textblocks oder Videos im Darstellungsbereich an — gerechnet ab dem Moment, in dem der Nutzer die Seite aufgerufen hat. Wichtig für die Ursachensuche: In den LCP fließt die gesamte Zeit vor dem Rendern ein, also auch das Verlassen der vorherigen Seite, der Verbindungsaufbau, Weiterleitungen und andere Verzögerungen bis zum ersten Byte. Ein langsamer Server oder eine Weiterleitungskette schlägt hier direkt durch, noch bevor irgendein Bild geladen wird.

Berücksichtigt werden laut Spezifikation nur bestimmte Elementtypen: Bilder, Bilder in SVG-Elementen, Videos, Elemente mit einem per url() geladenen Hintergrundbild und Blockelemente mit Text.

Interaction to Next Paint

INP misst die Reaktionsfähigkeit: die Zeit von einer Nutzerinteraktion bis zu dem Moment, in dem der Browser das nächste Bild zeichnen kann. Eine Interaktion ist dabei eine Gruppe von Ereignissen, die zu derselben logischen Aktion gehören — ein Tippen umfasst etwa pointerdown, pointerup und click. Gemeldet wird in der Regel die schlechteste Interaktion einer Sitzung.

INP hat 2024 den früheren Messwert First Input Delay ersetzt. Wer noch mit FID-Zahlen arbeitet, arbeitet mit einem eingestellten Messwert.

Cumulative Layout Shift

CLS misst, wie stark sichtbarer Seiteninhalt unerwartet verrutscht — der Text, der wegspringt, weil ein Bild ohne reservierte Höhe nachlädt, oder der Klick, der auf dem falschen Button landet, weil ein Banner eingeblendet wurde. Google weist ausdrücklich darauf hin, dass CLS früher die Summe aller Verschiebungen über die gesamte Lebensdauer der Seite war; heute wird das größte zusammenhängende Fenster gewertet.

Warum das 75. Perzentil

Core Web Vitals sind keine Durchschnittswerte. Google wertet das 75. Perzentil aller Seitenaufrufe aus, getrennt nach Mobilgeräten und Desktop-Geräten: Erreichen mindestens 75 Prozent der Aufrufe den Grenzwert für „gut", gilt die Website für diesen Messwert als gut; erreichen mindestens 25 Prozent den Grenzwert für „schlecht", gilt sie als schlecht.

Der Grund ist praktisch. Ein Mittelwert wird von schnellen Besuchen auf gutem Gerät und schnellem Netz geschönt, während die Hälfte der Nutzer eine schlechte Erfahrung hat. Das 75. Perzentil beschreibt, was die große Mehrheit tatsächlich erlebt — und es ist derselbe Wert für Mobil und Desktop, weil, wie Google schreibt, die Erwartung der Nutzer nicht vom Gerät abhängt, auch wenn die Erreichbarkeit es tut.

PageSpeed Insights: Labordaten und Felddaten

Der häufigste Irrtum in der Praxis ist die Verwechslung dieser beiden Datentypen, die PageSpeed Insights auf derselben Seite nebeneinander anzeigt.

	Felddaten	Labordaten
Quelle	Chrome User Experience Report (CrUX)	Lighthouse, simulierte Umgebung
Zeitraum	die letzten 28 Tage echter Besuche	ein einzelner Testlauf
Aussage	was Nutzer erlebt haben	wo die Ursachen liegen
Wofür	die Bewertung der Core Web Vitals	die Fehlersuche

Google beschreibt den Unterschied genau so: Labordaten sind nützlich zur Fehlerbehebung, weil sie in einer kontrollierten Umgebung entstehen, erkennen aber nicht immer die tatsächlichen Engpässe; Felddaten erfassen die reale Nutzererfahrung, umfassen dafür weniger Messwerte.

Drei Folgerungen für den Alltag:

• Der Lighthouse-Wert von 100 ist kein bestandener Core-Web-Vitals-Test. Die Bewertung entscheidet sich an den Felddaten.
• Neue oder wenig besuchte Seiten haben keine Felddaten. Reichen die Stichproben nicht, fällt PageSpeed Insights auf die Ebene der gesamten Domain zurück — und manchmal gibt es auch dort zu wenig.
• Änderungen brauchen Zeit, um sichtbar zu werden. Die Felddaten decken 28 Tage ab; ein Fix von gestern erscheint erst nach und nach.

Sind Core Web Vitals ein Rankingfaktor?

Google empfiehlt Websiteinhabern in der Search-Central-Dokumentation ausdrücklich, gute Core-Web-Vitals-Werte anzustreben, um in der Google Suche erfolgreich zu sein — und ordnet sie zusammen mit anderen Aspekten der Nutzerfreundlichkeit den Anforderungen der Ranking-Systeme zu.

Was das nicht heißt: dass eine schnelle Seite eine langsame mit besserem Inhalt überholt. Geschwindigkeit ist ein Faktor unter vielen und wirkt am stärksten dort, wo sich Inhalte ähneln. Der eigentliche Ertrag ist ohnehin ein anderer: Wer auf dem Telefon drei Sekunden auf den Preis wartet, geht zurück — unabhängig von der Position, auf der er geklickt hat.

Woran es in der Praxis scheitert

• Bilder ohne Größenangabe. Der Klassiker hinter schlechtem CLS: Breite und Höhe fehlen, das Layout springt beim Nachladen.
• Eingeblendete Banner. Cookie-Hinweise und Aktionsleisten, die über bestehenden Inhalt schieben, statt Platz zu reservieren.
• Drittanbieter-Skripte. Tag-Manager, Chatfenster, Testwerkzeuge — sie blockieren den Hauptthread und verschlechtern INP.
• Zu viel JavaScript beim ersten Laden. Besonders bei Anwendungen, die alles im Browser zusammenbauen, statt fertigen Text auszuliefern.
• Langsame Serverantwort. Fließt vollständig in den LCP ein und lässt sich mit Bildoptimierung nicht kompensieren.
• Schriftarten. Nachladende Webfonts erzeugen Textverschiebungen, wenn kein passender Ersatz definiert ist.

So macht es Xerx

Wir messen zuerst mit Felddaten und optimieren dann im Code. Der Unterschied klingt klein, entscheidet aber über den Nutzen: Ein Lighthouse-Lauf sagt uns, wo wir suchen sollen; ob ein Eingriff gewirkt hat, sagen uns die CrUX-Werte der folgenden Wochen. Beides gehört bei uns zu technischem SEO, und wir beheben die Ursachen selbst — blockierende Ressourcen, Layoutsprünge, langsame Serverantworten —, statt sie in einer Empfehlungsliste weiterzureichen.

Am wirksamsten ist die Arbeit vor dem Start. Bei Neubauten entstehen die Werte aus der Architektur: serverseitig gerendertes HTML, Bilder mit festen Abmessungen und modernen Formaten, Schriftarten mit definierter Ersatzdarstellung, so wenig Drittanbieter-Code wie vertretbar. Wie eine Seite auf verschiedenen Geräten überhaupt aufgebaut wird, gehört ebenfalls dazu — siehe Responsive Design; und wo das Frontend vom Redaktionssystem getrennt ist, lässt sich die Auslieferung deutlich direkter steuern, siehe Headless CMS.

Ehrlich zur Grenze: Nicht jede Website muss überall grün sein. Bei einer Seite mit wenigen hundert Besuchen im Monat existieren gar keine belastbaren Felddaten, und der Aufwand für die letzten Zehntelsekunden rechnet sich selten. Wir sagen, wo die Grenze des sinnvollen Aufwands liegt — und wir versprechen keine Ranking-Sprünge durch Geschwindigkeit allein, weil sie ein Faktor unter vielen ist.

FAQ