Core Web Vitals: LCP, INP und CLS verständlich erklärt
Die Core Web Vitals beschreiben zentrale Aspekte der Nutzungserfahrung: Ladeverhalten mit LCP, Reaktionsfähigkeit mit INP und visuelle Stabilität mit CLS.
Die Core Web Vitals sind drei Kennzahlen für die Nutzungserfahrung auf einer Webseite: LCP beschreibt das Ladeverhalten, INP die Reaktionsfähigkeit und CLS die visuelle Stabilität. Sie helfen dir zu erkennen, ob Besucher lange auf wichtige Inhalte warten, nach einem Klick eine verzögerte Reaktion sehen oder durch springende Seitenelemente gestört werden.
Für die Einordnung zählt nicht nur die Zahl. Du musst auch wissen, ob sie aus echten Besuchen oder einem einzelnen Test stammt. Ein guter Testwert ist keine Rankinggarantie; fehlende Nutzungsdaten sind umgekehrt kein bestandener Test.
Was messen die Core Web Vitals?
Die Kennzahlen betrachten drei unterschiedliche Probleme. Eine Seite kann schnell ihren wichtigsten Inhalt zeigen und trotzdem auf Eingaben träge reagieren. Ebenso kann sie zügig laden, während nachgeladene Elemente den Text verschieben. „Die Website ist schnell“ ist deshalb als Diagnose zu ungenau.
Die Core Web Vitals gehören zu Googles umfassenderer Web-Vitals-Initiative. Sie beschreiben ausgewählte, messbare Aspekte der Nutzung, nicht deren gesamte Qualität. Verständliche Texte, eine bedienbare Navigation oder ein funktionierendes Formular werden durch gute Werte nicht automatisch sichergestellt. Die Grundlagen von web.dev ordnen die drei Kennzahlen und ihre Messung ein.
Was bedeuten LCP, INP und CLS?
Largest Contentful Paint (LCP) erfasst, wann das größte relevante Bild- oder Textelement im sichtbaren Bereich dargestellt wird. Das ist ein Hinweis darauf, wann ein wesentlicher Teil der Seite sichtbar ist. LCP misst nicht, wann sämtliche Dateien vollständig geladen sind.
Interaction to Next Paint (INP) betrachtet die Reaktionszeit auf Interaktionen wie Klicks, Tippen und Tastatureingaben bis zur nächsten visuellen Aktualisierung. Eine Seite mit schlechtem INP kann bereits fertig geladen aussehen, sich bei der Bedienung aber zäh anfühlen. Der Wert beschreibt nicht die Dauer einer vollständigen Bestellung oder einer beliebig langen Serververarbeitung.
Cumulative Layout Shift (CLS) bewertet unerwartete Layoutverschiebungen. Ein anschauliches Beispiel: Du willst einen Link anklicken, doch ein nachgeladenes Element schiebt ihn kurz vorher nach unten. CLS ist ein dimensionsloser Wert, keine Zeitangabe. Die Kennzahl soll helfen, solche Instabilität von bloßer Ladegeschwindigkeit zu unterscheiden.
Welche Werte gelten als gut?
Die folgende Übersicht zeigt die Gut-Grenzen. Achte auf die verschiedenen Einheiten: Sekunden, Millisekunden und ein Wert ohne Einheit dürfen nicht wie drei vergleichbare Zeitmessungen gelesen werden.
| Kennzahl | Frage | Gut |
|---|---|---|
| LCP | Wann erscheint der größte sichtbare Inhalt? | ≤ 2,5 Sekunden |
| INP | Wie schnell wird eine Interaktion sichtbar beantwortet? | ≤ 200 Millisekunden |
| CLS | Wie stabil bleibt das Layout? | ≤ 0,1, ohne Einheit |
Das 75. Perzentil bedeutet vereinfacht: Mindestens 75 Prozent der betrachteten Werte liegen auf oder unter diesem Wert. Ein schneller Aufruf auf deinem eigenen Rechner reicht also nicht aus. Für eine bestandene Gesamtbewertung müssen die verfügbaren, erforderlichen Messwerte die jeweiligen Gut-Grenzen erfüllen; eine einzelne grüne Kennzahl gleicht eine schlechte andere nicht aus.
Was unterscheiden Feld- und Labordaten?
Felddaten entstehen bei echten Besuchen mit unterschiedlichen Geräten, Verbindungen und Interaktionen. Googles Chrome User Experience Report, kurz CrUX, liefert solche Daten. Labordaten entstehen dagegen unter definierten Testbedingungen. Sie sind besonders hilfreich, um einen Fehler nachzustellen oder eine Änderung vor der Veröffentlichung zu vergleichen.
| Prüfung | Felddaten | Labordaten |
|---|---|---|
| Grundlage | Tatsächliche Besuche | Definierter Testlauf |
| Hauptfrage | Was erleben Nutzer? | Was passiert unter diesen Bedingungen? |
| Stärke | Probleme im Nutzungskontext erkennen | Ursachen reproduzieren und Änderungen prüfen |
| Grenze | Ausreichend Daten erforderlich | Kein Ersatz für reale Nutzung |
In der Search Console werden ähnliche URLs gruppiert. Die Kennzahlen beziehen sich dort auf ein zurückliegendes 28-Tage-Fenster. Deshalb muss der Gruppenstatus nicht zum Einzeltest einer bestimmten Seite passen. Auch ein frisch verbesserter Testlauf ersetzt die historischen Besuche nicht sofort. Die Search-Console-Dokumentation erläutert diese Unterschiede und die nötige Datengrundlage.
Fehlen Felddaten, kannst du trotzdem im Labor prüfen. Das Ergebnis lautet dann aber nicht „reale Nutzung nachweislich gut“, sondern „unter diesen Testbedingungen geprüft“. Für INP gilt außerdem: Ein gewöhnlicher Lighthouse-Ladetest misst nicht einfach die gesamte spätere Interaktion. Dort kann unter anderem Total Blocking Time bei der Diagnose helfen, ist aber nicht mit INP gleichzusetzen.
Welche Rolle spielen die Werte für SEO?
Google bestätigt, dass seine Rankingsysteme Core Web Vitals verwenden. Gleichzeitig stellt Google ausdrücklich klar, dass gute Werte keine Spitzenposition garantieren. Inhaltliche Relevanz bleibt entscheidend; ein perfekter Leistungswert macht eine unpassende Antwort nicht zur besten Antwort. Diese Abgrenzung steht in Googles Hinweisen zur Nutzerfreundlichkeit von Seiten.
Behandle auffällige Werte deshalb als konkretes Nutzungsproblem, nicht als Erklärung für jeden Rankingverlust. Ebenso wäre es falsch, gute Werte als Beweis zu nehmen, dass technisch sonst alles in Ordnung ist. Indexierbarkeit und Performance sind unterschiedliche Prüfungen.
Wie priorisiert man auffällige Ergebnisse?
Beginne mit der betroffenen Kennzahl, dem Gerätetyp und der Datenquelle. Prüfe dann, welche Seitentypen betroffen sind und ob sich das Problem an mehreren Beispielen reproduzieren lässt. Eine gemeinsame Vorlage kann wichtiger sein als eine einzelne Ausnahme.
Ein illustrativer Fall: Mehrere wichtige Leistungsseiten haben auf Mobilgeräten einen schlechten LCP. Dann lohnt sich die Untersuchung gemeinsamer Ladebestandteile. Ein instabiler Formularbereich wäre dagegen zunächst ein CLS-Problem; zusätzliches Bildkomprimieren löst nicht automatisch dessen Ursache.
Halte vor einer Änderung fest, welche Ursache du vermutest und woran du eine Verbesserung erkennen willst. Prüfe die Änderung zunächst reproduzierbar und beobachte anschließend die Felddaten. Wenn mehrere technische Befunde zusammenkommen, kannst du sie mit unserer SEO-Audit-Checkliste im Zusammenhang bewerten. Entscheidend ist eine bessere Nutzung wichtiger Seiten, nicht das Sammeln möglichst vieler grüner Anzeigen.
Bereit für mehr Rankings?
Wissen ist der erste Schritt — professionelle Umsetzung der zweite.