Core Web Vitals verstehen: LCP, INP und CLS ohne Fachchinesisch
Die Core Web Vitals messen, wie schnell der größte Inhalt einer Seite erscheint (LCP), wie zügig sie auf Eingaben reagiert (INP) und wie ruhig ihr Layout bleibt (CLS). Als gut gelten bis 2,5 Sekunden, bis 200 Millisekunden und höchstens 0,1, jeweils für drei von vier Seitenaufrufen echter Besucher.
Die drei Abkürzungen stehen für Fragen aus Sicht des Besuchers: Sehe ich zügig, weswegen ich gekommen bin? Passiert etwas, wenn ich tippe? Bleibt der Button dort, wo ich hinziele? Google misst die Antworten bei echten Nutzern von Chrome und fasst sie im Chrome UX Report (CrUX) zusammen. Diese Daten tauchen in PageSpeed Insights und im Core-Web-Vitals-Bericht der Google Search Console auf.
Bewertet werden die Besuche der letzten 28 Tage. Ein Test am eigenen Rechner zeigt dagegen einen einzelnen Seitenaufruf unter Laborbedingungen, und deshalb liefern beide selten dieselbe Zahl; die Gründe stehen im Abschnitt zu Labor- und Felddaten, die Grenzwerte aus der Dokumentation von web.dev in der Tabelle darunter.
Grenzwerte
Drei Messwerte, drei Erlebnisse
Die Tabelle nennt die Schwellen, die web.dev und der Search-Console-Bericht verwenden. Dazwischen liegt jeweils ein mittleres Band, das die Search Console „Optimierung erforderlich“ nennt: beim LCP über 2,5 bis 4 Sekunden, beim INP über 200 bis 500 Millisekunden, beim CLS über 0,1 bis 0,25.
Bewertet wird das 75. Perzentil aller Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Bei 1.000 mobilen Aufrufen einer Seite müssen also mindestens 750 ihren größten Inhalt nach spätestens 2,5 Sekunden zeigen. Die übrigen 250 dürfen langsamer sein, ohne dass der Wert kippt. Eine Seite besteht die Prüfung in PageSpeed Insights nur, wenn alle drei Werte am 75. Perzentil gut sind; fehlen genug INP-Daten, entscheiden LCP und CLS allein.
| gut | schlecht | |
|---|---|---|
| LCP: größter sichtbarer Inhalt ist dargestellt | bis 2,5 Sekunden | über 4 Sekunden |
| INP: Reaktion auf Klick, Tippen oder Taste | bis 200 Millisekunden | über 500 Millisekunden |
| CLS: Summe unerwarteter Verschiebungen | bis 0,1 | über 0,25 |
Laden
LCP: wann der Hauptinhalt sichtbar ist
Largest Contentful Paint misst die Zeit vom Start des Seitenaufrufs, bis das größte Bild, der größte Textblock oder das größte Video im sichtbaren Bereich dargestellt ist. Auf einer Startseite kann das ein großes Titelbild oder die Hauptüberschrift sein, in einem Shop das Produktfoto.
web.dev zerlegt den Wert in vier Teile und nennt grobe Richtwerte für ihren Anteil:
Antwortzeit des Servers (Time to First Byte), etwa 40 Prozent.
Verzögerung, bis das Bild überhaupt angefordert wird, unter 10 Prozent.
Ladedauer der Bilddatei, etwa 40 Prozent.
Verzögerung bis zur Darstellung, unter 10 Prozent.
Diese Aufteilung zeigt, wo die Zeit verloren geht. Einen Bremsklotz im zweiten Teil nennt die Dokumentation ausdrücklich: Das LCP-Bild darf nie mit loading="lazy" verzögert geladen werden. Genau das passiert, wenn ein Theme alle Bilder pauschal träge lädt. Für das voraussichtliche LCP-Bild empfiehlt web.dev stattdessen das Attribut fetchpriority="high", aber für höchstens ein oder zwei Bilder.
Reagieren
INP: wie schnell die Seite reagiert
Interaction to Next Paint erfasst jede Eingabe während des gesamten Besuchs, vom Klick auf einen Filter bis zum Tastendruck im Suchfeld, und misst die Zeit bis zum nächsten sichtbaren Bild. Der gemeldete Wert entspricht ungefähr der langsamsten Reaktion des Besuchs. Bremsen entstehen durch lange Aufgaben im Hauptthread des Browsers, zum Beispiel aus Tag-Managern, Chat-Widgets oder Consent-Bannern. Wie Sie solche Ursachen finden und in welcher Reihenfolge Sie sie angehen, steht in INP verbessern: Wenn Ihre Website träge auf Klicks reagiert.
Stabilität
CLS: ob Inhalte springen
Cumulative Layout Shift bewertet Verschiebungen, mit denen der Besucher nicht rechnet: Der Text rutscht nach unten, weil darüber ein Bild nachlädt, und der Finger trifft den falschen Link. Verschiebungen innerhalb von 500 Millisekunden nach einem Klick, Tippen oder Tastendruck zählen nicht, weil der Nutzer sie selbst ausgelöst hat.
Jede einzelne Verschiebung bekommt einen Wert aus zwei Faktoren: dem Anteil des Bildschirms, den die bewegten Elemente vorher und nachher zusammen berühren, mal der Strecke, um die sie sich bewegen, gemessen am Bildschirm. web.dev rechnet ein Beispiel vor: Ein Element bedeckt die halbe Bildschirmhöhe und rutscht um ein Viertel der Höhe nach unten. Zusammen berührt es vorher und nachher 75 Prozent der Fläche, der Weg beträgt 25 Prozent. 0,75 mal 0,25 ergibt 0,1875. Diese eine Verschiebung reicht, um den Grenzwert von 0,1 zu überschreiten; die Seite landet im mittleren Band.
Verschiebungen, die weniger als eine Sekunde auseinanderliegen, bilden ein Zeitfenster von höchstens fünf Sekunden. Der CLS-Wert ist die Summe im schlechtesten dieser Fenster; Verschiebungen außerhalb davon zählen nicht mit.
Als häufige Ursachen nennt web.dev Bilder ohne Größenangabe, Werbung, Einbettungen und iframes ohne reservierten Platz, nachträglich eingefügte Inhalte und Webschriften. Die Abhilfe steht gleich daneben: width und height an jedem Bild und Video, die CSS-Eigenschaft aspect-ratio für flexible Einbettungen und eine Mindesthöhe für Banner, die erst nach dem Laden erscheinen.
Messen
Labor- und Felddaten unterscheiden
PageSpeed Insights zeigt zwei Ergebnisse untereinander, und sie messen verschiedene Dinge. Oben stehen Felddaten aus CrUX: echte Besuche der letzten 28 Tage, ausgewertet am 75. Perzentil. Unten steht ein Lighthouse-Lauf: ein einzelner, simulierter Seitenaufruf auf einem Testgerät mit festgelegter Verbindung.
Laut web.dev weichen beide aus mehreren Gründen voneinander ab:
Gerät und Netz: Das Labor kennt ein Gerät, das Feld alle Smartphones, Laptops und Verbindungen Ihrer Besucher.
Zwischenspeicher: Lighthouse lädt mit leerem Cache, wiederkehrende Besucher haben Bilder und Skripte oft schon gespeichert.
LCP-Element: Bildschirmgröße, Personalisierung oder A/B-Tests können im Feld ein anderes Element zum größten machen.
CLS: Das Labor sieht nur Verschiebungen beim Laden im ersten sichtbaren Bereich, das Feld auch solche beim Scrollen.
INP: Im Standardmodus klickt Lighthouse nichts an und meldet stattdessen die Total Blocking Time als Hinweis.
Dazu schwankt die Lighthouse-Punktzahl zwischen zwei Läufen, weil Netz und Rechner des Testservers nie gleich ausgelastet sind. Für Prioritäten zählen nach web.dev die Felddaten; das Labor dient der Ursachensuche und dem Test einer Änderung vor dem Ausrollen.
Der Search-Console-Bericht arbeitet mit denselben Felddaten, fasst aber ähnliche URLs zu Gruppen zusammen. Eine Gruppe bekommt den schlechtesten Status ihrer drei Werte: Ist LCP gut und CLS schlecht, steht die Gruppe auf „schlecht“.
Bevor Sie eine Zahl bewerten, prüfen Sie, wen die Felddaten abbilden. CrUX zählt nur Chrome auf Desktop und Android von Nutzern, die Synchronisierung und Nutzungsstatistik aktiviert haben; Chrome auf dem iPhone und Safari fließen nicht ein. Und aufgenommen werden nur öffentlich auffindbare Seiten mit genug Besuchern. Ein Kundenportal hinter einer Anmeldung ist nicht öffentlich auffindbar und fehlt damit voraussichtlich, und eine kleine Website hat unter Umständen nur einen Wert für die ganze Domain statt für einzelne Seiten. In beiden Fällen bleibt nur die eigene Messung im Browser der Besucher.
Suche
Was Google zum Ranking sagt
Google formuliert vorsichtiger, als manche Werkzeuge suggerieren. In der Dokumentation zur Seitenerfahrung steht: „Core Web Vitals are used by our ranking systems.“ Gleich daneben: „there's more to great page experience than Core Web Vitals scores alone.“ Und auf die Frage nach einem einzelnen Signal: „There is no single signal.“
Die Seite zu den Core Web Vitals enthält eine Empfehlung, keine Pflicht: „We highly recommend site owners achieve good Core Web Vitals for success with Search“. Gleichzeitig heißt es, die Suche zeige die relevantesten Inhalte, „even if the page experience is sub-par“. Gute Werte sind damit vor allem eine Frage der Nutzererfahrung und ein Faktor unter vielen in der Suchmaschinenoptimierung. Wie die Werte mit Inhalt und Autorität zusammenspielen, ordnet SEO ohne Buzzword-Bingo ein.
Messwerte im Alltag
Häufige Fragen
-
Google schreibt, dass seine Ranking-Systeme die Core Web Vitals nutzen, betont aber, dass es kein einzelnes Signal für die Seitenerfahrung gibt. Relevanz geht vor: Ein passender Inhalt kann auch mit mittelmäßigen Werten oben stehen. Google empfiehlt gute Werte, macht eine Platzierung aber nicht davon abhängig.
-
Die Punktzahl unten in PageSpeed Insights stammt aus einem einzelnen simulierten Lighthouse-Lauf und schwankt von Test zu Test. Die Bewertung oben beruht auf echten Chrome-Besuchen der letzten 28 Tage. Ändern Sie etwas, sehen Sie es im Labor sofort, im Feld erst nach und nach, weil ältere Besuche noch im Zeitraum stecken.
-
INP hat am 12.03.2024 First Input Delay (FID) als Core Web Vital abgelöst. FID maß nur die Wartezeit vor der ersten Eingabe eines Besuchs, INP die Reaktion auf alle Eingaben bis zum nächsten sichtbaren Bild. Chrome hat FID zugleich abgekündigt; Anwendungen, die FID aus den Schnittstellen von CrUX oder PageSpeed Insights lasen, sollten bis 09.09.2024 auf INP umstellen.
Search Console zeigt Rot, und niemand weiß, warum?
Im Performance-Audit-Sprint werten wir Lighthouse, Core Web Vitals und Backend-Tracing in zwei Wochen gemeinsam aus und übergeben einen priorisierten Maßnahmenplan, mit dem Ihr Team weiterarbeiten kann.
Nachweise
Quellen und Stand
Stand: 19.06.2026. Grenzwerte und Messmethoden laut web.dev und Google-Dokumentation; die Zitate zur Seitenerfahrung stammen aus der englischen Google-Dokumentation.
Artikel teilen