Core Web Vitals bezeichnen drei Performance-Metriken von Google zur Messung der Nutzererfahrung: Largest Contentful Paint (LCP) für Ladezeit, Interaction to Next Paint (INP) für Reaktionsfähigkeit und Cumulative Layout Shift (CLS) für visuelle Stabilität. Diese Web-Vitals-Kennzahlen fließen seit Juni 2021 als Page-Experience-Signal in das Google-Ranking ein. Website-Betreiber nutzen die CWV-Metriken, um die technische Qualität ihrer Seiten objektiv zu bewerten und gezielt zu verbessern.
Was sind Core Web Vitals?
Core Web Vitals bilden eine Untergruppe der Web Vitals und konzentrieren sich auf drei messbare Aspekte der Nutzererfahrung. Google führte diese Kernmetriken im Mai 2020 ein, um Website-Betreibern klare Richtwerte für eine gute User Experience zu liefern. Das Ziel: Messbare Standards statt vager Empfehlungen.
Die Core Web Vitals gehören zur sogenannten Page Experience, die neben den drei Leistungsmetriken weitere Faktoren umfasst: HTTPS-Verschlüsselung, Mobile-Friendliness und der Verzicht auf störende Interstitials (Einblendungen, die den Hauptinhalt überdecken). Google bewertet diese Page-Experience-Signale gemeinsam als Rankingfaktor für die SERPs.
Die Core Web Vitals unterscheiden sich von anderen Performance-Metriken durch ihre Datenbasis: Die Messwerte basieren auf Feld-Daten echter Chrome-Nutzer, nicht auf simulierten Labortests. Google sammelt diese Nutzerdaten über den Chrome User Experience Report (CrUX) und nutzt sie zur Bewertung von Websites. Die Feld-Daten spiegeln damit die tatsächliche Nutzererfahrung wider – unter realen Bedingungen mit unterschiedlichen Geräten, Browsern und Netzwerkgeschwindigkeiten.
Google aktualisiert die Core Web Vitals bei Bedarf, um neue Erkenntnisse zur Nutzererfahrung abzubilden. Im März 2024 ersetzte INP den bisherigen First Input Delay (FID) als Metrik für Reaktionsfähigkeit. Diese Weiterentwicklung zeigt: Die Kernmetriken passen sich dem technischen Fortschritt an.
Die drei Core Web Vitals im Überblick
Die drei Kernmetriken decken unterschiedliche Aspekte der Seitenperformance ab: LCP misst die wahrgenommene Ladegeschwindigkeit, INP erfasst die Reaktionszeit auf Nutzerinteraktionen und CLS bewertet die Layoutstabilität während des Seitenaufbaus. Gemeinsam bilden diese Web-Vitals-Werte ein umfassendes Bild der technischen Seitenqualität.
Für jede Metrik definiert Google drei Bewertungsstufen: gut, verbesserungswürdig und schlecht. Die folgende Tabelle zeigt die Grenzwerte im Detail:
| Metrik | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|
| LCP | ≤ 2,5 Sekunden | 2,5 – 4,0 Sekunden | > 4,0 Sekunden |
| INP | ≤ 200 Millisekunden | 200 – 500 Millisekunden | > 500 Millisekunden |
| CLS | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Die Bewertung einer URL basiert auf dem 75. Perzentil aller Seitenaufrufe. Das 75. Perzentil beschreibt den Wert, den 75 Prozent aller Messungen erreichen oder unterschreiten. Google wählt diesen statistischen Schwellenwert, weil er Ausreißer ausgleicht und die typische Nutzererfahrung abbildet. Eine URL gilt als „gut“, wenn mindestens drei Viertel der echten Seitenbesuche den Grenzwert erreichen.
Was misst der Largest Contentful Paint (LCP)?
Der Largest Contentful Paint erfasst die Ladezeit des größten sichtbaren Elements im Viewport – also im Bereich, den Nutzer ohne Scrollen sehen. Dieser Bereich wird auch als „above the fold“ bezeichnet, ein Begriff aus der Zeitungsbranche für den sichtbaren Teil über der Falzkante. Typische LCP-Elemente sind Hero-Bilder, große Textblöcke, Produktfotos oder Videos oberhalb der Scrollgrenze.
Die LCP-Metrik unterscheidet sich von älteren Ladezeit-Messungen: Time to First Byte (TTFB) misst nur die Server-Antwortzeit, First Contentful Paint (FCP) erfasst das erste gerenderte Element. Der Largest Contentful Paint hingegen bildet die wahrgenommene Ladegeschwindigkeit aus Nutzersicht ab – also den Moment, in dem die Seite „fertig“ wirkt.
Google stuft einen LCP-Wert unter 2,5 Sekunden als gut ein. Werte zwischen 2,5 und 4,0 Sekunden gelten als verbesserungswürdig, alles über 4,0 Sekunden als schlecht. Die 2,5-Sekunden-Schwelle orientiert sich an Studien zur Nutzerwahrnehmung: Ab dieser Verzögerung sinkt die Zufriedenheit messbar.
Optimierungsansätze für den Largest Contentful Paint:
Die Server-Antwortzeit lässt sich durch Caching (Zwischenspeicherung häufig angefragter Inhalte) und optimiertes Hosting verbessern. Ein Content Delivery Network (CDN) verkürzt die physische Distanz zwischen Server und Nutzer.
Bilder profitieren von Komprimierung und modernen Formaten wie WebP, das bei gleicher Qualität kleinere Dateigrößen erreicht. Lazy Loading – das verzögerte Laden von Bildern unterhalb des sichtbaren Bereichs – reduziert die initiale Datenmenge.
Render-blocking Resources verzögern den Seitenaufbau: CSS und JavaScript, die der Browser vor dem Rendern vollständig laden muss. Das Auslagern unkritischer Skripte oder deren asynchrones Laden beschleunigt die Darstellung.
Für die LCP-Optimierung bietet HTML das Attribut fetchpriority=“high“, das dem Browser signalisiert, bestimmte Ressourcen wie das Hero-Bild priorisiert zu laden.
Was misst Interaction to Next Paint (INP)?
Interaction to Next Paint erfasst die Reaktionszeit einer Website auf Nutzerinteraktionen wie Klicks, Taps oder Tastatureingaben. Die INP-Metrik misst die Zeit vom Beginn der Interaktion bis zum nächsten sichtbaren Update der Benutzeroberfläche – also bis der Nutzer eine Reaktion wahrnimmt.
Am 12. März 2024 ersetzte Google INP offiziell den bisherigen First Input Delay (FID) als Core Web Vital. Der Wechsel erfolgte aus einem wichtigen Grund: FID erfasste nur die Verzögerung bei der ersten Interaktion. INP hingegen berücksichtigt alle Interaktionen während des gesamten Seitenbesuchs und bewertet die langsamste davon. Die INP-Metrik liefert damit ein umfassenderes Bild der tatsächlichen Reaktionsfähigkeit.
Ein weiterer Unterschied zwischen FID und INP: FID maß nur die Eingabeverzögerung – die Zeit, bis der Browser mit der Verarbeitung beginnt. INP erfasst den gesamten Zeitraum bis zum visuellen Feedback, einschließlich Verarbeitungszeit und Rendering. Diese ganzheitliche Messung entspricht der Nutzerwahrnehmung besser.
Google bewertet einen INP-Wert unter 200 Millisekunden als gut. Werte zwischen 200 und 500 Millisekunden sind verbesserungswürdig, über 500 Millisekunden gelten als schlecht. Die 200-Millisekunden-Schwelle entspricht der menschlichen Wahrnehmungsgrenze für „sofortige“ Reaktionen.
Optimierungsansätze für Interaction to Next Paint:
JavaScript-Optimierung steht im Fokus: Lange Tasks (Berechnungen über 50 Millisekunden) blockieren den Main Thread des Browsers und verzögern Reaktionen. Das Aufteilen komplexer Berechnungen in kleinere Einheiten verbessert die Reaktionsfähigkeit.
Drittanbieter-Skripte wie Analytics, Chat-Widgets oder Werbetracker belasten die Performance. Das Reduzieren oder verzögerte Laden dieser externen Ressourcen entlastet den Browser.
Event-Handler – die Funktionen, die auf Nutzerinteraktionen reagieren – sollten schlank bleiben. Unnötige Berechnungen oder DOM-Manipulationen während der Verarbeitung verzögern das visuelle Feedback.
Code-Splitting bezeichnet das Aufteilen von JavaScript-Bundles in kleinere Pakete. Statt den gesamten Code beim Seitenaufruf zu laden, lädt der Browser nur die benötigten Module. Code-Splitting beschleunigt die initiale Interaktivität erheblich.
Was misst der Cumulative Layout Shift (CLS)?
Der Cumulative Layout Shift quantifiziert unerwartete Layoutverschiebungen während des Seitenaufbaus. Wenn Elemente ihre Position ändern, nachdem sie bereits sichtbar sind, verschlechtert das die CLS-Bewertung. Solche Verschiebungen frustrieren Nutzer – etwa wenn ein Button „wegspringt“, während man ihn anklicken möchte.
Typische Ursachen für Layoutverschiebungen sind: Bilder oder Videos ohne definierte Größenangaben im HTML-Code, nachladende Werbebanner, die Platz beanspruchen, Web Fonts, die nach dem Rendering den Textfluss verändern, sowie eingebettete iFrames ohne reservierten Platzbedarf.
Die CLS-Berechnung folgt einer Formel: Impact Fraction multipliziert mit Distance Fraction. Die Impact Fraction beschreibt den prozentualen Anteil des Viewports, den das verschobene Element vor und nach der Verschiebung einnimmt. Die Distance Fraction gibt an, wie weit sich das Element relativ zur Viewport-Höhe oder -Breite bewegt hat. Ein Element, das 50 Prozent des Viewports einnimmt und sich um 25 Prozent der Viewport-Höhe verschiebt, erzeugt einen CLS-Beitrag von 0,125.
Google stuft einen CLS-Wert unter 0,1 als gut ein. Werte zwischen 0,1 und 0,25 sind verbesserungswürdig, über 0,25 gelten als schlecht. Der Grenzwert 0,1 bedeutet: Maximal 10 Prozent des sichtbaren Bereichs verschiebt sich unerwartet.
Optimierungsansätze für den Cumulative Layout Shift:
Breite und Höhe für alle Bilder und Videos im HTML zu definieren verhindert Nachladesprünge. Der Browser reserviert den Platz bereits vor dem vollständigen Laden des Mediums.
Für Werbeflächen und dynamische Inhalte sollten feste Platzbereiche reserviert werden. Ein leerer Container mit definierten Abmessungen verhindert Verschiebungen beim Nachladen.
Web Fonts verursachen häufig einen „Flash of Unstyled Text“ (FOUT) – kurzzeitig erscheint ein Fallback-Font, dann springt der Text. Das Vorladen wichtiger Schriftarten mit rel=“preload“ oder die Verwendung von font-display: swap mit ähnlichen System-Fonts reduziert diesen Effekt.
Inhalte sollten niemals oberhalb bereits sichtbarer Elemente eingefügt werden. Neue Elemente gehören ans Ende des sichtbaren Bereichs oder unterhalb der Scrollposition.
Wie werden Core Web Vitals gemessen?
Google unterscheidet zwei Datentypen für die Performance-Messung: Labor-Daten und Feld-Daten. Beide Messarten haben unterschiedliche Anwendungszwecke und Stärken.
- Labor-Daten (Lab Data): Synthetische Messungen unter kontrollierten Bedingungen. Tools wie Lighthouse simulieren den Seitenaufruf mit definierten Netzwerk- und Geräteparametern. Labor-Daten sind reproduzierbar, vergleichbar und eignen sich zum Identifizieren technischer Probleme. Der Nachteil: Labor-Daten spiegeln nicht die reale Nutzererfahrung wider, da sie nur eine Momentaufnahme unter idealisierten Bedingungen darstellen.
- Feld-Daten (Field Data): Echte Messwerte von Chrome-Nutzern, gesammelt über den Chrome User Experience Report (CrUX). Diese Real User Metrics (RUM) basieren auf tatsächlichen Seitenbesuchen mit unterschiedlichen Geräten, Browsern und Netzwerkqualitäten. Die Feld-Daten bilden die Grundlage für Googles Ranking-Bewertung der Core Web Vitals.
Für die Ranking-Berechnung verwendet Google ausschließlich Feld-Daten. Labor-Daten helfen beim Debugging (der systematischen Fehlersuche), aber die finale Bewertung basiert auf dem 75. Perzentil der echten Nutzerdaten über einen Zeitraum von 28 Tagen.
Die Bewertung erfolgt getrennt für Desktop und Mobile. Eine URL kann auf dem Smartphone schlechte und am Desktop gute Werte aufweisen – oder umgekehrt. Google bewertet beide Geräteklassen separat in den Suchergebnissen.
Welche Tools messen Core Web Vitals?
Verschiedene Google-Tools ermöglichen die Messung und Analyse der Core Web Vitals. Jedes Tool hat spezifische Stärken für unterschiedliche Anwendungsfälle.
- Google Search Console: Zeigt den CWV-Bericht mit Feld-Daten für die gesamte Domain. Die Search Console gruppiert URLs nach Status (gut, verbesserungswürdig, schlecht) und identifiziert problematische Seiten. Die Search-Console-Daten basieren auf echten Nutzern und sind für die Ranking-Bewertung relevant. Website-Betreiber sollten diesen Bericht regelmäßig prüfen.
- PageSpeed Insights: Kombiniert Feld-Daten aus CrUX mit Labor-Daten aus Lighthouse. PageSpeed Insights analysiert einzelne URLs und liefert konkrete Optimierungsvorschläge für jede Metrik. PageSpeed Insights zeigt sowohl die Ranking-relevanten Feld-Daten als auch detaillierte technische Empfehlungen.
- Lighthouse: Labor-basiertes Audit-Tool, integriert in Chrome DevTools und als eigenständige Anwendung verfügbar. Lighthouse simuliert Seitenaufrufe und identifiziert Performance-Probleme detailliert. Die Lighthouse-Ergebnisse dienen dem Debugging und der Entwicklung, nicht der direkten Ranking-Bewertung.
- Chrome DevTools: Ermöglichen Live-Messungen während der Entwicklung. Der Performance-Tab zeigt detaillierte Analysen von Interaktionen, Layoutverschiebungen und Ladezeiten. Entwickler nutzen die DevTools zur gezielten Problemanalyse.
- Web Vitals Extension: Browser-Erweiterung für Chrome, die CWV-Werte in Echtzeit anzeigt. Die Web-Vitals-Extension eignet sich für schnelle Überprüfungen während des normalen Browsens.
Wie beeinflussen Core Web Vitals das Google-Ranking?
Google integrierte die Core Web Vitals im Juni 2021 mit dem Page Experience Update als offiziellen Rankingfaktor. Die Gewichtung der CWV-Metriken fällt jedoch moderat aus – Content-Qualität und thematische Relevanz bleiben die dominanten Ranking-Signale für die Sichtbarkeit in den SERPs.
John Mueller, Senior Webmaster Trends Analyst bei Google, formulierte die Gewichtung so: Qualitativ hochwertiger Content steht weiterhin an erster Stelle. Die Page Experience wird wichtiger, wenn mehrere ähnliche Ergebnisse um dieselbe Position konkurrieren. Die Core Web Vitals fungieren also als Tiebreaker – bei ansonsten gleichwertigen Seiten entscheidet die bessere Performance über die Platzierung.
Eine Sistrix-Studie aus dem Jahr 2021 quantifizierte den Ranking-Effekt der Core Web Vitals: Websites mit guten CWV-Werten zeigten durchschnittlich 1 Prozentpunkt mehr Sichtbarkeit im Sichtbarkeitsindex als der Durchschnitt. Seiten mit schlechten Performance-Metriken verloren hingegen 3,7 Prozentpunkte. Der Einfluss ist messbar, aber nicht dominierend – technische Exzellenz ersetzt keinen mangelhaften Content.
Googles eigene Untersuchungen belegen einen weiteren Effekt: Nutzer brechen den Seitenbesuch mit 24 Prozent geringerer Wahrscheinlichkeit ab, wenn eine Website die CWV-Grenzwerte erfüllt. Gute Core Web Vitals verbessern also nicht nur das Ranking in den Suchergebnissen, sondern auch die tatsächliche Nutzerinteraktion, die Verweildauer und die Konversionsraten.
Die Optimierung der Core Web Vitals lohnt sich besonders für Seiten, die bereits relevanten Content bieten und in kompetitiven SERPs um Top-Positionen konkurrieren. Für Websites mit grundlegenden Content-Problemen haben technische Verbesserungen weniger Priorität.