Was sind Core Web Vitals — und warum sind sie relevant
Google hat die Core Web Vitals als standardisiertes Set von Metriken eingeführt, um die wahrgenommene Qualität einer Seite aus Nutzerperspektive zu quantifizieren. Sie sind Teil des sogenannten Page Experience Signals und fließen in das Ranking ein — allerdings als einer von vielen Faktoren, nicht als alleiniger Hebel.
Die drei aktuellen Core Web Vitals sind:
- LCP (Largest Contentful Paint): Wie schnell wird das größte sichtbare Element geladen?
- INP (Interaction to Next Paint): Wie reaktionsschnell reagiert die Seite auf Nutzereingaben?
- CLS (Cumulative Layout Shift): Wie stabil bleibt das Layout während des Ladens?
Wichtig: Google bewertet diese Metriken auf Basis von Field Data — also echten Nutzerdaten aus dem Chrome User Experience Report (CrUX), nicht aus Labortests. Das bedeutet, dass synthetische Tests in PageSpeed Insights nur ein Indikator sind, nicht das finale Urteil.
Im Rahmen einer vollständigen Technical-SEO-Strategie gehören Core Web Vitals zu den Bereichen, die regelmäßig überprüft werden sollten — besonders nach größeren Deployments oder CMS-Updates.
LCP: Was er misst und wie man ihn verbessert
Der Largest Contentful Paint misst, wann das größte sichtbare Element im Viewport vollständig gerendert ist. Das kann ein Hero-Bild, ein großes Textelement oder ein Video-Thumbnail sein. Google empfiehlt einen LCP-Wert von unter 2,5 Sekunden.
Die häufigsten LCP-Probleme
- Unkomprimierte oder nicht in modernen Formaten (WebP, AVIF) ausgelieferte Bilder
- Fehlendes
fetchpriority="high"auf dem LCP-Element - Render-blocking Ressourcen (CSS, JavaScript), die den Browser aufhalten
- Langsame Serverantwortzeiten (TTFB über 600 ms)
- Lazy Loading auf dem LCP-Bild — ein häufiger Fehler
Konkrete Maßnahmen für besseren LCP
Das LCP-Element sollte so früh wie möglich im HTML stehen und mit <link rel='preload'> vorgeladen werden. Ein typisches Beispiel für ein Hero-Bild:
<link rel='preload' as='image' href='/hero.webp' fetchpriority='high'>Zusätzlich sollte das Bild selbst kein loading='lazy' Attribut tragen — Lazy Loading ist sinnvoll für Bilder unterhalb des Folds, aber kontraproduktiv für das LCP-Element.
Serverseitig lohnt sich der Einsatz von CDNs mit Edge-Caching sowie HTTP/2 oder HTTP/3. Die Auswirkungen von Protokolloptimierungen auf Performance und Ranking sind im Artikel zu HTTPS und HTTP/2 detailliert beschrieben.
Für JavaScript-lastige Seiten gilt: Wenn das LCP-Element erst durch clientseitiges Rendering erscheint, ist das ein strukturelles Problem. JavaScript SEO und Core Web Vitals hängen hier direkt zusammen — serverseitiges Rendering (SSR) oder Static Site Generation (SSG) sind in solchen Fällen die effektivsten Lösungen.
INP: Die neue Interaktivitätsmetrik
INP hat im März 2024 den bisherigen FID (First Input Delay) als Core Web Vital abgelöst. Während FID nur die erste Interaktion maß, erfasst INP die Reaktionszeit aller Interaktionen während einer Sitzung — und nimmt den schlechtesten Wert (mit Ausnahme von Ausreißern). Google empfiehlt einen INP-Wert unter 200 Millisekunden.
Was INP verschlechtert
- Langer Main-Thread-Blocking durch schweres JavaScript
- Synchrone Event-Handler, die aufwendige DOM-Operationen auslösen
- Third-Party-Scripts (Chat-Widgets, Analytics, Ad-Tags), die den Main Thread blockieren
- Fehlende Priorisierung von Nutzerinteraktionen gegenüber Hintergrundprozessen
INP verbessern — praktische Ansätze
Der erste Schritt ist die Identifikation problematischer Interaktionen. Das Chrome DevTools Performance Panel zeigt Long Tasks (Aufgaben über 50 ms) und deren Verursacher. Alternativ liefert die Web Vitals Extension im Browser direkte INP-Werte pro Interaktion.
Technisch helfen folgende Maßnahmen:
- JavaScript-Code in kleinere, nicht-blockierende Chunks aufteilen (
requestIdleCallback,setTimeoutmit 0 ms) - Event-Handler debouncing bei Scroll- und Input-Events
- Third-Party-Scripts in Web Workers auslagern oder mit
async/deferladen - React- und Vue-Anwendungen: Unnötige Re-Renders durch Memoization reduzieren
Bei komplexen Single-Page-Applications ist INP oft das hartnäckigste Problem. Hier lohnt sich eine systematische Analyse mit dem Chrome Profiler, bevor man an einzelnen Symptomen arbeitet.
CLS: Visuelle Stabilität messen und sicherstellen
Der Cumulative Layout Shift misst, wie stark sich Seitenelemente während des Ladens unerwartet verschieben. Ein CLS-Wert unter 0,1 gilt als gut. Hohe CLS-Werte entstehen, wenn Elemente nachträglich in das Layout eingefügt werden und andere Inhalte verschieben — ein klassisches Beispiel sind Werbebanner oder Schriften, die nach dem initialen Render laden.
Typische CLS-Ursachen
- Bilder ohne definierte
width- undheight-Attribute - Web Fonts, die nach dem Laden springen (FOUT/FOIT)
- Dynamisch eingefügte Inhalte (Cookie-Banner, Newsletter-Popups, Ads)
- Animationen, die Layout-Eigenschaften wie
top,leftodermarginverändern
CLS systematisch beheben
Die effektivste Maßnahme ist, für alle Bilder und Medienelemente explizite Dimensionen im HTML zu setzen:
<img src='/bild.webp' width='800' height='450' alt='Beschreibung'>Für Web Fonts empfiehlt sich font-display: optional oder font-display: swap in Kombination mit Preloading der wichtigsten Schriftschnitte. Cookie-Banner und andere dynamische Elemente sollten Platz reservieren, bevor sie erscheinen — etwa durch feste Höhenangaben im CSS oder durch Platzhalter-Elemente.
Animationen sollten ausschließlich transform und opacity verwenden, da diese auf dem Compositor-Thread laufen und kein Layout-Reflow auslösen.
Core Web Vitals messen — die richtigen Tools
Es gibt zwei grundlegend verschiedene Arten von Daten:
- Field Data (Real User Monitoring): Echte Nutzerdaten aus CrUX, verfügbar in Google Search Console, PageSpeed Insights und dem CrUX Dashboard. Diese Daten sind maßgeblich für das Google-Ranking.
- Lab Data (Synthetische Tests): Simulierte Tests in PageSpeed Insights, Lighthouse, WebPageTest oder GTmetrix. Nützlich für Diagnose und Entwicklung, aber nicht direkt ranking-relevant.
Die Google Search Console zeigt unter „Core Web Vitals" eine URL-Gruppierung mit Status „Gut", „Verbesserungsbedarf" oder „Schlecht" — basierend auf Field Data. Das ist der Ausgangspunkt für jede Optimierungsarbeit.
Für kontinuierliches Monitoring empfiehlt sich die Integration von web-vitals.js (Googles offizielle JavaScript-Bibliothek) in das eigene Analytics-Setup. So lassen sich INP, LCP und CLS pro Seite und Gerät tracken.
Wer mehrsprachige oder internationale Seiten betreibt, sollte beachten, dass Core Web Vitals pro URL gemessen werden. Bei DACH-Setups mit separaten Sprachversionen — wie in der Anleitung zu Hreflang Tags für DACH beschrieben — müssen alle Sprachvarianten einzeln überprüft werden.
Wie man Core Web Vitals sinnvoll priorisiert
Nicht jede Seite hat die gleichen Probleme, und nicht jede Seite ist gleich wichtig. Eine sinnvolle Priorisierung folgt diesem Schema:
- Search Console auswerten: Welche URL-Gruppen sind als „Schlecht" markiert? Welche haben hohes organisches Traffic-Volumen?
- LCP zuerst: LCP hat den größten Einfluss auf die wahrgenommene Ladegeschwindigkeit und ist in den meisten Fällen der dringlichste Hebel.
- CLS als Quick Win: CLS-Probleme lassen sich oft mit wenigen CSS-Anpassungen beheben und bringen schnelle Ergebnisse.
- INP als Projekt: INP-Optimierungen erfordern häufig tiefere JavaScript-Refactorings und sollten als eigenes Entwicklungsprojekt geplant werden.
Core Web Vitals sind kein einmaliges Projekt. Jedes neue Feature, jeder neue Third-Party-Script und jedes CMS-Update kann die Werte verschlechtern. Regelmäßige Audits — idealerweise als Teil eines technischen SEO-Prozesses — sind deshalb unerlässlich. Wie solche Audits strukturiert werden, zeigt die vollständige Technical-SEO-Checkliste.
Für Seiten, die stark auf Mobile-Traffic angewiesen sind, gilt zusätzlich: Da Google primär die mobile Version indexiert, sollten Core Web Vitals immer auch auf mobilen Geräten gemessen werden. Die Anforderungen an Mobile-First Indexing und Core Web Vitals überschneiden sich hier erheblich.