Core Web Vitals sind Kennzahlen für zentrale Aspekte der Seitenerfahrung. LCP bewertet, wann der größte sichtbare Inhalt geladen ist. INP betrachtet die Reaktionsfähigkeit bei Interaktionen. CLS misst unerwartete Layoutverschiebungen.
Google unterscheidet Felddaten realer Nutzer von Labordaten unter kontrollierten Bedingungen. PageSpeed Insights, Search Console und Browser-Tools können daher unterschiedliche Werte zeigen. Für Entscheidungen sollte zuerst geklärt werden, welcher Seitentyp, welches Gerät und welche Nutzergruppe betroffen ist.
Häufige Hebel
Bildformate und Dimensionen; kritische Ressourcen; Server-/Cache-Zeiten; JavaScript-Menge; Drittanbieter-Tags; Fonts; reservierter Platz für Medien; komponentenspezifische Analyse.
Gute Core Web Vitals sind kein Ersatz für hilfreichen Inhalt oder klare UX, verbessern aber Nutzung und technische Qualität.
Die drei Core Web Vitals im Detail
Largest Contentful Paint (LCP)
LCP misst, wann das größte relevante Inhaltselement im sichtbaren Bereich gerendert wurde. Das kann ein Hero-Bild, eine große Überschrift oder ein Textblock sein. Als guter Orientierungswert gilt laut web.dev ein LCP von höchstens 2,5 Sekunden für mindestens 75 Prozent der Seitenaufrufe.
Ein schlechter LCP kann durch langsame Serverantworten, nicht optimierte Bilder, renderblockierende Stylesheets, Webfonts, clientseitiges Rendering oder eine falsche Priorisierung des Hero-Mediums entstehen. Entscheidend ist, welches Element bei realen Seiten tatsächlich als LCP zählt.
Interaction to Next Paint (INP)
INP bewertet die Reaktionsfähigkeit über die Nutzung einer Seite hinweg. Gemessen wird, wie lange der Browser nach einer Interaktion benötigt, bis eine visuelle Reaktion dargestellt wird. Ein guter Wert liegt laut web.dev bei höchstens 200 Millisekunden am 75. Perzentil.
Häufige Ursachen sind lange JavaScript-Aufgaben, umfangreiche Drittanbieter-Skripte, komplexe Komponenten oder zu viel Arbeit im Hauptthread. Eine Schaltfläche kann optisch einfach sein und trotzdem langsam reagieren, wenn im Hintergrund große Prozesse synchron ausgeführt werden.
Cumulative Layout Shift (CLS)
CLS misst unerwartete Layoutverschiebungen während der Nutzung. Ein guter Wert liegt bei höchstens 0,1. Typische Probleme sind Bilder oder Werbeflächen ohne reservierte Dimensionen, nachträglich eingefügte Banner, wechselnde Fonts oder dynamische Komponenten oberhalb des sichtbaren Inhalts.
Nicht jede Bewegung ist schlecht. Eine vom Nutzer erwartete Animation nach einem Klick wird anders bewertet als ein Button, der kurz vor der Interaktion durch ein geladenes Bild wegrutscht.
Gute, verbesserungsbedürftige und schlechte Werte
| Kennzahl | Gut | Verbesserungsbedürftig | Schlecht |
|---|---|---|---|
| LCP | bis 2,5 s | über 2,5 bis 4,0 s | über 4,0 s |
| INP | bis 200 ms | über 200 bis 500 ms | über 500 ms |
| CLS | bis 0,1 | über 0,1 bis 0,25 | über 0,25 |
Die Beurteilung sollte getrennt für Mobilgeräte und Desktop sowie auf Basis des 75. Perzentils erfolgen. Ein guter Durchschnitt kann eine relevante Gruppe langsamer Nutzer verdecken.
Felddaten und Labordaten
Felddaten stammen von echten Chrome-Nutzern unter realen Geräten, Netzwerken und Interaktionen. Der Chrome User Experience Report fasst sie über einen rollierenden Zeitraum zusammen. Nicht jede kleine oder neue URL besitzt genügend Daten; dann werden möglicherweise Daten für eine URL-Gruppe oder den Ursprung gezeigt.
Labordaten entstehen in einer kontrollierten Simulation. Lighthouse und PageSpeed Insights helfen, Ursachen reproduzierbar zu diagnostizieren. Sie können jedoch nicht jede reale Interaktion oder Gerätekombination abbilden.
Ein typischer Fall: Im Labor ist LCP grün, in Felddaten aber schlecht. Mögliche Gründe sind langsamere reale Geräte, Nutzer in anderen Ländern, Cookie-Banner, personalisierte Inhalte oder eine andere Trafficverteilung. Beide Datentypen widersprechen sich dann nicht — sie beantworten unterschiedliche Fragen.
Welche Tools helfen?
- PageSpeed Insights: verbindet verfügbare Felddaten mit einer Lighthouse-Analyse;
- Google Search Console: zeigt URL-Gruppen mit ähnlichen Problemen aus Felddaten;
- Chrome DevTools: untersucht Netzwerk, Performance, Layout Shifts und lange Aufgaben;
- Lighthouse: liefert reproduzierbare Labordiagnosen und Verbesserungshinweise;
- Real User Monitoring: misst die eigene Nutzerbasis mit zusätzlichen Segmenten und Release-Bezug.
Eine einzelne Punktzahl ist nicht das Projektziel. Entscheidend sind die drei Kennzahlen, konkrete Seitentypen und der reale Geschäftskontext.
LCP systematisch verbessern
- LCP-Element je Template identifizieren.
- Serverantwort und Caching prüfen.
- kritisches Bild in passender Größe und modernem Format ausliefern.
- das LCP-Medium nicht unnötig lazy laden.
- wichtige Ressource früh entdecken und bei Bedarf priorisieren.
- kritische CSS- und Font-Abhängigkeiten reduzieren.
- clientseitige Renderketten verkürzen.
Ein übergroßes Hero-Video kann visuell attraktiv sein, aber den ersten Eindruck verlangsamen. Dann werden Poster, Komprimierung, Ladeverhalten oder ein alternatives Motiv getestet, statt die Markenwirkung pauschal zu entfernen.
INP systematisch verbessern
Lange Aufgaben werden in kleinere Einheiten zerlegt, damit der Browser zwischendurch reagieren kann. Nicht benötigtes JavaScript wird reduziert oder später geladen. Event Handler führen nur die notwendige unmittelbare Arbeit aus. Aufwendige Berechnungen können ausgelagert, Listen virtualisiert und Drittanbieter-Tags begrenzt werden.
Da INP reale Interaktionen betrachtet, müssen typische Funktionen getestet werden: Navigation, Akkordeons, Filter, Suche, Warenkorb, Formulare und Consent-Banner. Eine schnelle Startseite garantiert keinen schnellen Produktfilter.
CLS systematisch verbessern
- Breite und Höhe beziehungsweise Seitenverhältnis für Bilder und Videos reservieren;
- Platz für Banner, Embeds und Werbeflächen vorhalten;
- neue Inhalte nicht unerwartet oberhalb der aktuellen Position einfügen;
- Fonts sinnvoll vorladen und Fallback-Metriken abstimmen;
- Animationen mit performanten Eigenschaften umsetzen;
- Komponenten in realistischen Lade- und Fehlerzuständen testen.
Auch nach dem ersten Laden können Verschiebungen auftreten. Deshalb sind Session-Daten und Interaktionen wichtig, nicht nur ein Screenshot der Startphase.
Drittanbieter, Consent und Tracking
Chat, Heatmaps, A/B-Testing, Werbung und umfangreiche Tag-Manager-Container können Performance beeinträchtigen. Jedes Skript sollte einen benannten Eigentümer, einen Zweck und einen Prüfzeitpunkt haben. Nicht mehr benötigte Tags werden entfernt. Consent darf dabei nicht umgangen werden; Technik und Datenschutz werden gemeinsam geplant.
Core Web Vitals und SEO
Google nennt Core Web Vitals als Teil der Seitenerfahrung. Gute Werte garantieren jedoch kein Ranking und schlechtere Werte bedeuten nicht automatisch, dass eine relevante Seite nie rankt. Inhalt, Suchintention und viele weitere Signale bleiben entscheidend.
Der geschäftliche Nutzen geht über SEO hinaus: schnellere, stabile und reaktionsfähige Seiten können Nutzerfrust senken und Formulare, Checkout oder Produktnavigation verbessern. Deshalb werden Performance und Conversion gemeinsam betrachtet.
Performance-Budget und kontinuierliche Kontrolle
Ein einmaliges Optimierungsprojekt kann durch neue Bilder, Kampagnen-Tags oder Komponenten wieder verloren gehen. Ein Performance-Budget definiert Grenzen für beispielsweise JavaScript, Bildgewicht oder zentrale Kennzahlen je Template. Automatisierte Checks im Entwicklungsprozess erkennen grobe Verschlechterungen; Felddaten bestätigen die reale Wirkung.
Nach Releases sollte festgehalten werden, wann eine Änderung live ging. So können Teams Veränderungen in Felddaten, Fehlern und Conversions besser zuordnen.
Priorisierung nach Seitentyp
Nicht jede URL wird einzeln behandelt. Häufig teilen Produktseiten, Artikel oder Landingpages dieselbe Vorlage. Ein Fix am Template kann tausende URLs verbessern. Priorität erhalten Seitentypen mit viel relevantem Traffic, kritischer Conversion oder deutlich schlechtem Nutzererlebnis.
Häufige Fehler
- nur die Lighthouse-Gesamtpunktzahl optimieren;
- Desktop messen und mobile Felddaten ignorieren;
- alle Bilder blind komprimieren, aber das LCP-Element nicht identifizieren;
- notwendige Funktionen entfernen, ohne Geschäftswirkung zu prüfen;
- ein Cache-Plugin installieren und keine Templates testen;
- nach dem Projekt kein Monitoring etablieren;
- technische Werte als garantierten Rankinghebel verkaufen.
Core-Web-Vitals-Checkliste
- Feld- und Labordaten getrennt erfassen.
- betroffene Templates und Geräte bestimmen.
- LCP-Element, lange Interaktionen und Layout Shifts reproduzieren.
- Ursachen nach Wirkung und Aufwand priorisieren.
- Änderungen in Staging und auf realen Geräten testen.
- Deployment-Datum dokumentieren.
- Felddaten über den notwendigen Zeitraum beobachten.
- Budget und Monitoring in den Entwicklungsprozess integrieren.
Häufige Fragen zu Core Web Vitals
Sind Core Web Vitals ein Rankingfaktor?
Sie gehören zu den Signalen der Seitenerfahrung. Sie sind kein Ersatz für Relevanz und hilfreichen Inhalt und garantieren keine bestimmte Position.
Reicht ein grüner Desktop-Wert?
Nein. Mobile und Desktop-Nutzung unterscheiden sich. Für die offizielle Einordnung sind reale Felddaten und das 75. Perzentil wichtig.
Kann ein Plugin alle Probleme lösen?
Selten dauerhaft. Ein Plugin kann Caching oder Medienoptimierung unterstützen, aber ungeeignete Architektur, umfangreiche Skripte und Komponentenlogik benötigen gezielte Entwicklungsarbeit.
Warum ändern sich Werte nicht sofort nach einem Fix?
Labordaten reagieren direkt. Aggregierte Felddaten bilden einen längeren realen Zeitraum ab und benötigen genügend neue Seitenaufrufe.
Muss jede URL grün sein?
Ziel ist ein gutes Erlebnis für den überwiegenden Teil realer Nutzer. Priorisiert werden wiederkehrende Template-Probleme und geschäftlich wichtige Seiten, nicht kosmetische Perfektion einzelner Messungen.