Core Web Vitals

Core Web Vitals sind drei von Google definierte Kennzahlen, die Ladegeschwindigkeit, Interaktivität und visuelle Stabilität einer Webseite anhand realer Nutzerdaten bewerten. Google stellte die Web-Vitals-Initiative im Mai 2020 vor. Seit Juni 2021 fließen die Metriken als Bestandteil des Page-Experience-Signals in das Ranking ein. Im März 2024 ersetzte Interaction to Next Paint (INP) den bisherigen First Input Delay (FID) als zweite Kernmetrik. Laut dem Chrome User Experience Report erfüllen nur rund 40 Prozent aller Websites alle drei Schwellenwerte gleichzeitig. Die Optimierung dieser Metriken gehört zu den wichtigsten Aufgaben der technischen Suchmaschinenoptimierung.

Was sind Core Web Vitals?

Core Web Vitals sind drei standardisierte Leistungskennzahlen, die Google zur Bewertung der Nutzererfahrung auf Webseiten heranzieht: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS).

Die Bewertung basiert auf dem 75. Perzentil der Felddaten im Chrome User Experience Report (CrUX). Eine Seite gilt nur dann als “gut”, wenn mindestens 75 Prozent aller Seitenaufrufe die jeweiligen Schwellenwerte einhalten. Jede Metrik deckt einen Kernaspekt der Nutzererfahrung ab: LCP misst, wie schnell der wichtigste sichtbare Inhalt geladen wird. INP misst, wie reaktionsschnell die Seite auf Nutzerinteraktionen reagiert. CLS misst, wie stabil das Layout während des Seitenaufbaus bleibt.

Ergänzende diagnostische Messwerte wie Time to First Byte (TTFB), First Contentful Paint (FCP) und Total Blocking Time (TBT) helfen bei der Fehlersuche, fließen aber nicht direkt in die Core-Web-Vitals-Bewertung ein.

Welche Metriken gehören zu den Core Web Vitals?

Die drei Core Web Vitals messen jeweils einen anderen Aspekt der Seitenperformance: Ladegeschwindigkeit (LCP), Reaktionsfähigkeit (INP) und visuelle Stabilität (CLS). Jede Metrik hat drei Bewertungsstufen mit klar definierten Schwellenwerten.

Metrik	Was wird gemessen	Gut	Verbesserung nötig	Schlecht
Largest Contentful Paint (LCP)	Ladezeit des größten sichtbaren Elements	≤ 2,5 s	2,5 - 4,0 s	> 4,0 s
Interaction to Next Paint (INP)	Reaktionszeit auf Nutzerinteraktionen	≤ 200 ms	200 - 500 ms	> 500 ms
Cumulative Layout Shift (CLS)	Unerwartete Layout-Verschiebungen	≤ 0,1	0,1 - 0,25	> 0,25

Was misst Largest Contentful Paint (LCP)?

LCP erfasst die Renderzeit des größten sichtbaren Inhaltselements im Viewport. Das ist typischerweise ein Hero-Bild, eine große Textüberschrift oder ein Videovorschaubild. Google misst den Zeitpunkt, an dem dieses Element vollständig gerendert ist, relativ zum Start des Seitenladens.

Vier Ursachen sind für die meisten langsamen LCP-Werte verantwortlich. Die Optimierung dieser Faktoren verbessert den LCP-Wert in der Regel am deutlichsten, weil sie direkt die Renderzeit des größten sichtbaren Elements beeinflussen.

• Unkomprimierte Bilder: Hero-Bilder in PNG oder JPEG ohne Kompression verlangsamen den Seitenaufbau erheblich. WebP und AVIF reduzieren die Dateigröße um 25 bis 50 Prozent.
• Langsame Server-Antwortzeiten: Ein TTFB über 800 Millisekunden verzögert den gesamten Ladevorgang. Serverseitiges Caching und CDN-Einsatz senken die Antwortzeit.
• Render-blockierende Ressourcen: CSS- und JavaScript-Dateien im Head, die den Browser am Rendern hindern, verschieben den LCP nach hinten.
• Fehlende Preload-Hints: Ohne explizites Preloading entdeckt der Browser das LCP-Element erst spät im Ladeprozess. Ein <link rel="preload"> für das Hero-Bild beschleunigt die Erkennung.

Was misst Interaction to Next Paint (INP)?

INP erfasst die Latenz zwischen einer Nutzerinteraktion (Klick, Tipp, Tasteneingabe) und der nächsten visuellen Aktualisierung des Bildschirms. Im März 2024 löste INP den bisherigen First Input Delay (FID) offiziell als Core Web Vital ab.

Der entscheidende Unterschied zu FID: INP bewertet alle Interaktionen während des gesamten Seitenbesuchs, nicht nur die erste. Der schlechteste gemessene Wert (beim 98. Perzentil bei Seiten mit vielen Interaktionen) bestimmt den INP-Score. Werte unter 200 Millisekunden gelten als gut.

INP setzt sich aus drei Phasen zusammen, die jeweils unterschiedliche Ursachen für langsame Reaktionszeiten aufdecken. Jede Phase erfordert eigene Optimierungsansätze, um die Gesamtlatenz einer Interaktion zu reduzieren.

• Input Delay: Die Wartezeit, bis der Browser mit der Verarbeitung beginnt, weil der Main Thread durch andere Tasks blockiert ist. Lange JavaScript-Aufgaben über 50 Millisekunden sind die häufigste Ursache.
• Processing Time: Die Dauer der Event-Handler-Ausführung. Komplexe DOM-Manipulationen, Zustandsänderungen oder Netzwerkanfragen im Handler verlängern diese Phase.
• Presentation Delay: Die Zeit für Rendering und Compositing bis zur nächsten visuellen Aktualisierung. Style-Berechnungen und Layout-Neuberechnungen verursachen die meisten Verzögerungen.

Warum hat INP den First Input Delay (FID) ersetzt?

FID maß ausschließlich die Verzögerung der ersten Nutzerinteraktion und ignorierte die Verarbeitungszeit sowie das visuelle Feedback. INP liefert ein realistischeres Bild der Reaktionsfähigkeit, weil es alle Interaktionen über die gesamte Sitzung erfasst.

Kriterium	FID (bis März 2024)	INP (seit März 2024)
Gemessene Interaktionen	Nur die erste	Alle während der Sitzung
Erfasste Phasen	Nur Input Delay	Input Delay + Processing + Presentation
Schwellenwert (gut)	≤ 100 ms	≤ 200 ms
Berichteter Wert	Einzelmessung	Annähernd schlechteste Interaktion (P98)
Aussagekraft	Begrenzt (nur erster Eindruck)	Umfassend (gesamte Sitzung)

Was misst Cumulative Layout Shift (CLS)?

CLS quantifiziert unerwartete Verschiebungen sichtbarer Elemente während des Seitenaufbaus. Die Berechnung multipliziert den Anteil des verschobenen Bereichs (Impact Fraction) mit der Verschiebungsdistanz (Distance Fraction). Ein CLS-Wert von maximal 0,1 gilt als gut.

Vier Auslöser verursachen die meisten Layout-Verschiebungen. Google bewertet CLS auf Basis von Session Windows, wobei kurze Verschiebungsphasen zusammengefasst werden. Bewusste Verschiebungen durch Nutzeraktionen wie Klicks auf Accordions oder Tabs fließen nicht in die Berechnung ein.

• Bilder ohne definierte Abmessungen: Der Browser reserviert keinen Platz und verschiebt nachfolgende Inhalte, sobald das Bild geladen wird. Width- und Height-Attribute oder CSS aspect-ratio verhindern das.
• Nachladende Werbebanner: Werbeflächen ohne reservierten Platz drücken den Content nach unten. Ein festes min-height für Ad-Container löst das Problem.
• Dynamisch eingefügte Elemente: Cookie-Banner, Newsletter-Popups oder Chat-Widgets, die ohne feste Position erscheinen und bestehenden Content verdrängen.
• Web Fonts mit Layoutverschiebung: Systemschrift wird durch eine Webfont ersetzt, deren Maße abweichen. font-display: swap oder font-display: optional in Kombination mit Font-Preloading stabilisiert das Layout.

Warum sind Core Web Vitals ein Google-Rankingfaktor?

Core Web Vitals bilden zusammen mit HTTPS, Mobilfreundlichkeit und dem Verzicht auf aufdringliche Interstitials das Page-Experience-Signal. Die Metriken wirken primär als Tiebreaker: Bei gleichwertiger inhaltlicher Relevanz entscheidet die technische Performance über die Platzierung.

Google rollte das Page Experience Update in vier Phasen aus. Der Rollout erstreckte sich über neun Monate und machte Core Web Vitals schrittweise zum Bestandteil des Ranking-Algorithmus für alle Gerätetypen.

• Juni 2021: Beginn des Rollouts für die mobile Suche.
• August 2021: Rollout für mobile Suche abgeschlossen.
• Februar 2022: Beginn des Rollouts für die Desktop-Suche.
• März 2022: Desktop-Rollout abgeschlossen. Core Web Vitals wirken seitdem auf allen Gerätetypen als Rankingsignal.

Eine Seite mit starkem Content und schlechten Core-Web-Vitals-Werten fällt im Ranking hinter eine ähnlich relevante Seite mit besserer Performance zurück. Core Web Vitals allein heben keine schwache Seite auf Seite 1. Sie können aber den Unterschied zwischen Position 5 und Position 3 ausmachen. Im Dezember 2023 entfernte Google Mobilfreundlichkeit als eigenständiges Ranking-Signal, weil die Mehrheit aller Websites inzwischen mobile-friendly ist. Core Web Vitals bleiben als Performance-Signal bestehen.

Wie werden Core Web Vitals gemessen?

Google stellt sechs Tools bereit, die Felddaten von echten Nutzern oder Labordaten aus simulierten Tests liefern. Für die Rankingbewertung zählen ausschließlich die Felddaten aus dem Chrome User Experience Report.

Tool	Datentyp	Besonderheiten
Google Search Console	Felddaten (CrUX)	LCP, INP, CLS gruppiert nach URL-Status, direkt mit Indexierungsdaten verknüpft
PageSpeed Insights	Feld- und Labordaten	Alle Core Web Vitals plus diagnostische Metriken und Handlungsempfehlungen
Lighthouse	Labordaten	LCP, CLS, TBT (als INP-Proxy), integriert in Chrome DevTools
Chrome User Experience Report	Felddaten	Öffentlich via BigQuery und API, 28-Tage-Durchschnitt
Chrome DevTools	Labordaten	Performance-Panel mit detaillierter Timeline und Flame Charts
web-vitals.js	Felddaten (eigene Erhebung)	JavaScript-Bibliothek zur Messung auf der eigenen Website

Was ist der Unterschied zwischen Field Data und Lab Data?

Felddaten stammen von echten Chrome-Nutzern unter realen Bedingungen. Google verwendet ausschließlich Felddaten aus dem Chrome User Experience Report für die Ranking-Bewertung. Diese Daten umfassen verschiedene Gerätetypen, Netzwerkgeschwindigkeiten und Standorte.

Labordaten werden in kontrollierten Testumgebungen erhoben, etwa durch Lighthouse mit simulierter Netzwerkdrosselung. Labordaten eignen sich zur Diagnose und zum Debugging, bilden aber nicht die Vielfalt realer Nutzungsbedingungen ab. INP kann in Labordaten nicht vollständig gemessen werden, weshalb Lighthouse Total Blocking Time (TBT) als Proxy verwendet.

Ein häufiges Szenario: Lighthouse zeigt einen Score von 95, während die Felddaten gleichzeitig schlechte Werte melden. Langsame Mobilgeräte, schwankende Netzwerkverbindungen und geografische Entfernungen zum Server erfassen nur Felddaten. Für die Rankingbewertung zählen ausschließlich die CrUX-Felddaten.

Wie lassen sich Core Web Vitals verbessern?

Jede der drei Metriken erfordert gezielte technische Maßnahmen. Die wirkungsvollsten Optimierungen adressieren die häufigsten Ursachen für schlechte Werte: unkomprimierte Bilder und langsame Server für LCP, blockierende JavaScript-Tasks für INP und fehlende Größenangaben für CLS.

Die folgenden sechs Maßnahmen decken die wichtigsten Hebel ab. Die Reihenfolge entspricht der typischen Priorisierung: LCP-Optimierungen zeigen die schnellsten Ergebnisse, INP-Verbesserungen erfordern tiefere JavaScript-Analyse und CLS-Fixes sind meist die einfachsten Änderungen.

• Bilder für LCP optimieren: Komprimiere Bilder in WebP oder AVIF, setze Width- und Height-Attribute und lade Above-the-Fold-Bilder per <link rel="preload"> priorisiert. Responsive Bilder mit dem srcset-Attribut liefern dem Browser die passende Bildgröße je nach Viewport.
• Server-Antwortzeit reduzieren: Ein TTFB unter 800 Millisekunden ist die Basis für gute LCP-Werte. Serverseitiges Caching, ein CDN und optimierte Datenbankabfragen senken die Antwortzeit. HTTP/2 oder HTTP/3 verbessern die Übertragung zusätzlich.
• Render-blockierende Ressourcen eliminieren: Nicht-kritisches JavaScript mit defer oder async verschieben. Critical CSS (das CSS für den sichtbaren Bereich) inline laden und den Rest asynchron nachladen.
• JavaScript-Ausführungszeit für INP minimieren: Lange Main-Thread-Tasks in kleinere Einheiten unter 50 Millisekunden zerlegen. Die scheduler.yield()-API gibt dem Browser zwischen Aufgaben Luft. Web Workers lagern rechenintensive Operationen in separate Threads aus.
• Layout-Verschiebungen für CLS verhindern: Feste Abmessungen (width, height oder aspect-ratio) für Bilder, Videos und Iframes definieren. Platz für Werbeflächen und dynamisch nachladende Elemente mit min-height reservieren.
• Web Fonts stabilisieren: font-display: swap oder font-display: optional verwenden. Schriften lokal hosten statt über externe Dienste laden und kritische Font-Dateien per <link rel="preload"> priorisieren. Subsetting reduziert die Dateigröße auf die tatsächlich verwendeten Zeichen.

Wie wirken sich Core Web Vitals auf die SEO-Gesamtstrategie aus?

Performance-Optimierung ist ein messbarer Ranking-Einflussfaktor mit konkreten Schwellenwerten. Neben Content-Qualität und Backlink-Profil gehört die technische Seitenperformance zu den drei Säulen, die bei einer professionellen SEO-Strategie kontinuierlich überwacht werden.

Seiten mit guter Performance werden von Googlebot häufiger gecrawlt, weil der Server schneller antwortet und weniger Abrufkapazität verbraucht wird. Das beschleunigt die Indexierung neuer Inhalte. Besonders bei einem Website-Relaunch spielen Core Web Vitals eine zentrale Rolle, weil Performance-Regressions nach dem Go-Live zu den häufigsten Ursachen für Sichtbarkeitsverluste gehören.

Für KI-basierte Suchergebnisse gilt: Seiten, die technisch performant und semantisch sauber strukturiert sind, haben die besten Voraussetzungen für Sichtbarkeit in klassischen und KI-generierten Suchergebnissen. Eine gezielte Optimierung für generative KI-Suche profitiert von der technischen Grundlage, die gute Core Web Vitals schaffen.

Werden Core Web Vitals in Zukunft an Bedeutung gewinnen?

Google hat die Metriken seit 2020 dreimal aktualisiert: FID wurde durch INP ersetzt, die CLS-Berechnung wurde auf Session Windows umgestellt und die Schwellenwerte wurden angepasst. Jede Iteration zeigt, dass Google die Nutzererfahrung stärker quantifizieren will. Performance-Metriken als Rankingfaktor werden voraussichtlich weiter an Gewicht gewinnen.

Wie oft sollte man Core Web Vitals prüfen?

Die Google Search Console zeigt Core-Web-Vitals-Daten mit einem Verzug von etwa 28 Tagen. Eine monatliche Prüfung der Felddaten ist sinnvoll. Nach technischen Änderungen, CMS-Updates oder dem Einbau neuer Third-Party-Skripte lohnt sich eine sofortige Kontrolle mit Lighthouse und PageSpeed Insights.

Können sich Core Web Vitals verschlechtern, obwohl nichts geändert wurde?

Ja. Neue Browser-Versionen, veränderte Nutzergeräte oder steigende Serverlast können die Felddaten verschlechtern, ohne dass am Code etwas geändert wurde. Third-Party-Skripte (Werbung, Chat-Widgets, Consent-Banner) werden von ihren Anbietern aktualisiert und können die Performance beeinflussen. Regelmäßiges Monitoring über die Search Console und automatisierte Alerts über die CrUX API decken solche Regressionen frühzeitig auf.