Core Web Vitals: Werte verstehen und gezielt prüfen

Marktdenker · Veröffentlicht am

Core Web Vitals: Laden, Interaktion und Stabilität, dargestellt durch drei Papiermotive in Grün und Kupfer.

Core Web Vitals beschreiben drei Bereiche der Nutzung einer Webseite: Ladeleistung, Reaktionsschnelligkeit und visuelle Stabilität. Die aktuellen Kennzahlen heißen LCP, INP und CLS. Bevor du aus einem Wert eine Maßnahme ableitest, prüfe seine Datenquelle, den Gerätetyp und den Messbereich. Ein Labortest, eine einzelne URL und eine Gruppe realer Seitenbesuche beantworten unterschiedliche Fragen. Die drei Bereiche beschreibt Google Search Central.

Dieser Leitfaden hilft dir, einen Bericht zu verstehen und einen konkreten Untersuchungsauftrag zu formulieren. Für eine technische Änderung brauchst du anschließend eine überprüfte Ursache. Ein schlechter Messwert allein sagt noch nicht, welches Bild, Skript oder Seitenelement dafür verantwortlich ist.

In diesem Artikel:

Drei Kennzahlen, drei unterschiedliche Fragen

Largest Contentful Paint (LCP) beschreibt, wann das größte sichtbare Inhaltselement gerendert wird, etwa ein Bild oder ein Textblock. Das ist keine Messung dafür, wann sämtliche Bestandteile der Seite fertig geladen sind. Ein später geladenes, kleines Element muss diesen Wert deshalb nicht bestimmen. Die genaue Einordnung steht in der LCP-Dokumentation von web.dev.

Interaction to Next Paint (INP) beschreibt die Reaktionsfähigkeit bei Klicks, Berührungen und Tastatureingaben. Entscheidend ist die Verzögerung bis zur nächsten sichtbaren Rückmeldung. Das bedeutet beispielsweise: Reagiert ein Bedienelement erkennbar, nachdem du es benutzt hast? INP misst damit nicht die vollständige Dauer einer anschließenden Serveranfrage. Siehe die offizielle INP-Erklärung.

Cumulative Layout Shift (CLS) beschreibt unerwartete Verschiebungen sichtbarer Inhalte. Text, der beim Lesen plötzlich verrutscht, ist eine andere Art von Problem als langsames Laden. Der CLS-Wert hat keine Zeiteinheit. Die CLS-Dokumentation erklärt diesen Bereich der visuellen Stabilität.

Kennzahl Gut Optimierung erforderlich Schlecht
LCP bis einschließlich 2,5 Sekunden über 2,5 bis einschließlich 4 Sekunden über 4 Sekunden
INP bis einschließlich 200 Millisekunden über 200 bis einschließlich 500 Millisekunden über 500 Millisekunden
CLS bis einschließlich 0,1 über 0,1 bis einschließlich 0,25 über 0,25

Die Grenzen einschließlich der Grenzwerte sind in der Search-Console-Hilfe dokumentiert. Die Tabelle enthält Bewertungsgrenzen, keine Messung deiner Website.

Drei vereinfachte Browsermodelle unterscheiden sichtbaren Inhalt bei LCP, Rückmeldung nach Eingabe bei INP und unerwartete Bewegung bei CLS; daneben stehen die guten Grenzwerte.
Laden, Rückmeldung und Layoutstabilität sind drei unterschiedliche Prüfbereiche. Eigene vereinfachte Darstellung; gute Grenzen nach Google, keine gemessenen Websitewerte.

Falls du in einem älteren Ratgeber First Input Delay (FID) findest: INP hat FID 2024 als Core-Web-Vitals-Kennzahl ersetzt. Die aktuelle Web-Vitals-Übersicht dokumentiert diesen Wechsel. Eine alte FID-Bewertung lässt sich deshalb nicht einfach als aktuelle INP-Bewertung lesen.

Was das 75. Perzentil aussagt

Die Bewertung der Felddaten arbeitet mit dem 75. Perzentil, kurz p75. Dieser Wert wird von 75 Prozent der erfassten Besuche erreicht oder unterschritten. Er ist kein Durchschnitt; auch bei einem guten p75 können weitere Besuche schlechter abschneiden. Die PageSpeed-Insights-Dokumentation erklärt diese Verteilung.

Ein vereinfachtes Rechenbeispiel: Du betrachtest für denselben Gerätetyp 100 erfasste Besuche. Bei mindestens 75 davon liegt LCP bei höchstens 2,5 Sekunden. Das veranschaulicht die gute LCP-Grenze am p75. Die übrigen Besuche können längere Ladezeiten haben. Das Beispiel enthält keine realen Messdaten und bewertet nur LCP, nicht zusätzlich INP und CLS.

Betrachte Mobilgeräte und Computer getrennt. Eine gute Bewertung am Computer beantwortet nicht automatisch die Frage nach der mobilen Nutzung. Diese Trennung gehört zu den Empfehlungen für Web Vitals.

Für deine Notizen ist deshalb „LCP gut“ zu ungenau. Halte daneben fest, welchen Gerätetyp und welche Datenbasis du betrachtet hast. So bleibt später nachvollziehbar, ob zwei Berichte überhaupt dieselbe Frage beantworten.

Felddaten und Labortests ergänzen sich

Felddaten beschreiben tatsächliche Nutzung. Die in PageSpeed Insights eingebundenen Daten des Chrome User Experience Report, kurz CrUX, beziehen sich auf die letzten 28 Tage. Labordaten entstehen dagegen unter kontrollierten Bedingungen und helfen bei der Diagnose. PageSpeed Insights zeigt beide Perspektiven. Google erläutert ihre Unterschiede.

Die praktische Frage im Feld lautet: Welche Erfahrung haben die erfassten Nutzer gemacht? Im Labor lautet sie: Welches Verhalten lässt sich unter den gewählten Testbedingungen untersuchen? Notiere für einen Laborvergleich deshalb die Bedingungen und das getestete Nutzungsszenario. Ein einzelner Testlauf bildet nicht automatisch alle Geräte, Verbindungen und Interaktionen deiner Besucher ab.

Viele symbolische reale Besuche fließen über 28 Tage in eine Feldbewertung; ein kontrollierter Laborlauf untersucht ein gewähltes Szenario. Beide führen zu verschiedenen Erkenntnissen.
Felddaten zeigen erfasste Nutzung, ein Labortest hilft bei der Diagnose. Eigene schematische Darstellung nach Google; Symbole stehen für Besuche, nicht für eine gemessene Stichprobengröße.

Der Lighthouse-Performance-Score gehört zur Labordiagnose. Eine gute Labornote ersetzt keine gute Core-Web-Vitals-Feldbewertung. Auch Google trennt beide Bewertungen.

Bei INP kommt eine weitere Grenze hinzu: Ein Lighthouse-Ladevorgang ohne Nutzereingaben misst kein INP. Total Blocking Time (TBT) kann dabei als Diagnosehinweis dienen, ist aber kein Ersatz für INP. Labormessung von INP ist möglich, wenn passende Interaktionen simuliert werden. Das beschreibt die INP-Dokumentation. Prüfe daher, ob dein Test nur das Laden oder auch ein konkretes Bedienverhalten untersucht.

Erst prüfen, welche Seiten die Werte beschreiben

Die Search Console bündelt URLs mit ähnlicher Nutzererfahrung in Gruppen und bewertet Mobilgeräte und Computer separat. Der schlechteste verfügbare Messwert bestimmt den jeweiligen Gruppenstatus. Eine rote Gruppe beweist dadurch nicht, dass jede enthaltene URL genau dieselbe technische Ursache hat. Die Google-Hilfe zur Gruppierung erklärt auch mögliche Ausreißer.

PageSpeed Insights kann Felddaten für die eingegebene URL oder für ihren Ursprung, auch Origin genannt, anzeigen. Reichen die URL-Daten nicht aus, kann das Tool auf den Ursprung zurückgreifen. Reichen auch dessen Daten nicht, fehlen Felddaten. Ein Ursprungswert ist keine Messung ausschließlich der eingegebenen Seite. Siehe Google zum Datenumfang.

Bevor du Werte vergleichst, beantworte daher drei Fragen: Geht es um dieselbe Datenart? Um denselben Gerätetyp? Und um dieselbe URL, Gruppe oder denselben Ursprung? Halte diesen Umfang zusammen mit dem Datum fest. Ein scheinbarer Widerspruch zwischen zwei Ansichten kann zunächst eine unterschiedliche Betrachtung sein; die technische Ursache muss gesondert untersucht werden.

Fehlende Daten sind keine gute Bewertung

Keine Felddaten bedeuten nicht, dass die Seite gut abschneidet. Zu wenige erfasste Besuche oder eine neue Search-Console-Property können die Anzeige begrenzen. Die Search-Console-Hilfe beschreibt solche Fälle.

PageSpeed Insights nennt außerdem eine spezifische Bewertungsregel: Fehlen ausreichende INP-Daten, kann die Core-Web-Vitals-Bewertung bei guten LCP- und CLS-Werten bestanden sein. Fehlen ausreichende LCP- oder CLS-Daten, ist diese Bewertung nicht möglich. Diese PSI-Ausnahme macht INP nicht allgemein optional. Notiere die Datenlücke, statt aus einer Gesamtanzeige drei vorhandene Einzelwerte abzuleiten.

Aus Messwerten einen Untersuchungsauftrag machen

Beginne mit einem betroffenen Bereich, den du tatsächlich belegen kannst. Die Search-Console-Hilfe empfiehlt, schlechte Probleme zuerst anzugehen und innerhalb eines vergleichbaren Status die meisten oder wichtigsten betroffenen URLs zu beachten. Diese Priorisierung gibt eine Reihenfolge vor, noch keine fertige technische Lösung.

Für ein kleines Team eignet sich folgende redaktionelle Arbeitshilfe. Sie ist kein getestetes Erfolgsmodell:

  1. Befund sichern: Notiere Datenquelle, Datum, Gerätetyp, Messbereich, Kennzahl und Status. Bewahre den konkreten Bericht auf, statt nur „Website zu langsam“ weiterzugeben.
  2. Nutzungsszenario benennen: Was soll untersucht werden: sichtbarer Hauptinhalt, Rückmeldung auf eine Eingabe oder eine unerwartete Verschiebung? Beschreibe die Situation so konkret, dass die zuständige Person sie prüfen kann.
  3. Ursache untersuchen lassen: Trenne den beobachteten Befund von einer Vermutung. Ein auffälliger LCP-Wert ist beispielsweise noch kein Beweis, dass ausschließlich der Server schuld ist.
  4. Änderung und Verantwortung festhalten: Dokumentiere die bestätigte Ursache, die geplante Änderung und wer deren Prüfung übernimmt. So lässt sich später zuordnen, was tatsächlich geändert wurde.
  5. Erneut prüfen: Vergleiche passende Labortests und anschließend den dokumentierten Feldkontext. Bleibt ein Problem bestehen, ist die nächste Frage offen; eine Maßnahme gilt nicht allein durch ihre Umsetzung als erfolgreich.

Zur technischen Diagnose können weitere Kennzahlen helfen. Time to First Byte (TTFB) und First Contentful Paint (FCP) unterstützen die Untersuchung von LCP-Problemen; TBT ist ein Laborhinweis für mögliche Interaktionsprobleme. Sie werden dadurch nicht zu zusätzlichen Core Web Vitals. Diese Abgrenzung beschreibt web.dev.

Was Core Web Vitals für SEO bedeuten

Google nutzt Core Web Vitals in seinen Rankingsystemen. Gute Werte garantieren jedoch keine Spitzenposition in den Suchergebnissen. Inhaltliche Relevanz und weitere Aspekte der Nutzerfreundlichkeit bleiben wichtig; Google kann relevante Inhalte auch bei teilweise unterdurchschnittlicher Nutzererfahrung anzeigen. Das steht in der aktuellen Search-Central-Erklärung zur Nutzerfreundlichkeit.

Ordne die Messwerte deshalb in die Arbeit an der einzelnen Seite ein. Für Onpage-SEO ist die technische Nutzungserfahrung eine konkrete Prüfaufgabe neben der Frage, ob der Inhalt die gesuchte Aufgabe beantwortet. Eine bessere Labornote allein liefert keinen Nachweis, dass sich Sichtbarkeit oder Geschäftsergebnis verbessert haben.

Nach einer Änderung erneut beurteilen

Ein neuer Labortest kann die geänderte Seite untersuchen. Das rollierende 28-Tage-Fenster der Felddaten enthält zunächst weiterhin Besuche vor der Änderung. Behandle den neuen Laborlauf daher nicht als sofortige neue Feldbewertung. Die unterschiedlichen Zeitbezüge erläutert die PSI-Dokumentation.

Davon getrennt ist die Search-Console-Funktion zum Tracking behobener Probleme: Sie beobachtet laut Hilfe einen Zeitraum von 28 Tagen und löst keine Neuindexierung aus. Die Dokumentation zur Überprüfung ist eine Beschreibung dieser Funktion, keine Zusage, wann deine Seite gute Werte erreicht.

Auch Laborläufe können schwanken. Geräte-, Netzwerk- und Nutzungsbedingungen tragen außerdem zu Abweichungen zwischen Feld und Labor bei. Google erläutert diese Unterschiede. Vergleiche dokumentierte Bedingungen und den betroffenen Bereich, bevor du einen einzelnen Ausschlag als eindeutige Wirkung der Änderung interpretierst.

Die nächste sinnvolle Frage

Wenn der Messbereich klar ist, kannst du entscheiden, welche technische Untersuchung als Nächstes nötig ist. Websiteweite Ursachen gehören in die Arbeit am technischen SEO; die Überarbeitung einer einzelnen Seite braucht zusätzlich den Blick auf Inhalt und Struktur. Formuliere dafür einen begrenzten Auftrag mit Befund und offener Frage.

Im Bereich Content und SEO findest du die übergeordnete Orientierung für diese Aufgaben. Weitere Einordnungen zu Unternehmens- und Marketingfragen bündelt Business und Marketing bei Marktdenker.