Core Web Vitals

Was sind Core Web Vitals?

Die Core Web Vitals sind eine Sammlung von drei Messwerten, die Google 2020 eingeführt hat, um die Nutzererfahrung (User Experience) einer Webseite objektiv und vergleichbar zu messen. Sie sind Teil der „Page Experience Signals" und seit 2021 ein offiziell bestätigter Ranking-Faktor – wenn auch ein moderater im Vergleich zu inhaltlicher Relevanz.

Die drei Kernmetriken decken jeweils einen anderen Moment der Nutzerinteraktion ab:

Metrik	Was sie misst	Wann sie auftritt
LCP	Ladegeschwindigkeit des Hauptinhalts	Beim ersten Seitenaufbau
INP	Reaktionsgeschwindigkeit auf Interaktion	Während der Nutzung
CLS	Visuelle Stabilität des Layouts	Über die gesamte Sitzung

Zusammen beantworten sie die drei kritischen Fragen aus Nutzersicht: „Lädt es schnell? Reagiert es flott? Springt das Layout?"

LCP – Largest Contentful Paint

LCP misst die Zeit, bis das größte sichtbare Element im sichtbaren Bereich (Viewport) gerendert ist – meistens ein Hero-Bild, eine Hauptüberschrift oder ein Video-Thumbnail. Erst wenn dieses dominante Element steht, fühlt sich die Seite für Nutzer „fertig geladen" an.

Schwellenwerte

Wert	Bewertung
≤ 2,5 Sekunden	Gut
2,5 – 4,0 Sekunden	Verbesserung erforderlich
> 4,0 Sekunden	Schlecht

Was LCP beeinflusst

• Server-Antwortzeit: Eine langsame TTFB (Time to First Byte) verzögert alles
• Render-blockierende Ressourcen: CSS- und JavaScript-Dateien, die das Rendering aufhalten
• Bilder ohne Optimierung: Unkomprimierte, riesige Bilder als Hauptinhalt
• Schriftarten: Web Fonts, die spät geladen werden und Texte verzögern
• Client-seitiges Rendering: Bei Single-Page-Apps wartet der LCP, bis JavaScript gerendert hat

Schnelle Hebel für LCP

1. Hauptbild komprimieren und in modernem Format (WebP, AVIF) ausliefern
2. fetchpriority="high" für das LCP-Bild setzen
3. CDN nutzen, um die TTFB zu reduzieren
4. Render-blockierendes CSS inlinen oder asynchron laden
5. Preconnect / Preload für kritische Ressourcen

INP – Interaction to Next Paint

INP ist seit März 2024 die offizielle Metrik für Interaktivität – sie hat den älteren Wert FID (First Input Delay) abgelöst. INP misst die Reaktionszeit auf Nutzerinteraktionen über die gesamte Lebensdauer einer Seite: Wie lange dauert es, bis nach einem Klick, einem Tap oder einem Tastendruck eine sichtbare Reaktion erfolgt?

Anders als FID, das nur die erste Interaktion gemessen hat, betrachtet INP alle Interaktionen und nimmt typischerweise den schlechtesten Wert (mit Ausreißerkorrektur). Das ist näher an der echten Nutzererfahrung – eine Seite, die auf den ersten Klick schnell reagiert, danach aber träge wird, wird so realistisch bewertet.

Schwellenwerte

Wert	Bewertung
≤ 200 Millisekunden	Gut
200 – 500 Millisekunden	Verbesserung erforderlich
> 500 Millisekunden	Schlecht

Was INP beeinflusst

• Lange JavaScript-Tasks, die den Main Thread blockieren
• Schwere Event-Handler, die synchron viel Arbeit leisten
• Layout-Thrashing, wenn Skripte wiederholt Layouts berechnen lassen
• Third-Party-Skripte, die unkontrolliert Rechenzeit beanspruchen
• Komplexe React-/Vue-Komponenten mit teurem Re-Rendering

Schnelle Hebel für INP

1. Lange Tasks aufteilen mit requestIdleCallback oder Worker Threads
2. Debouncing/Throttling für häufig ausgelöste Handler (Scroll, Resize)
3. Third-Party-Skripte verzögert laden (async, defer, loading="lazy")
4. Hydration-Strategie überprüfen – Islands oder partielle Hydration nutzen
5. Code-Splitting, damit nicht für jede Interaktion das gesamte Skript geladen werden muss

CLS – Cumulative Layout Shift

CLS misst die visuelle Stabilität einer Seite. Wer kennt es nicht: Man will auf einen Button klicken, in dem Moment lädt eine Anzeige darüber nach, das Layout springt – und man klickt auf etwas Falsches. Diese ungewollten Verschiebungen sind nicht nur lästig, sondern können auch unbeabsichtigte Aktionen auslösen (etwa versehentliche Käufe).

CLS misst die Summe aller unerwarteten Layout-Verschiebungen während der gesamten Seitenlebensdauer. Eine „erwartete" Verschiebung, etwa nach einer Nutzerinteraktion (Klick auf „Mehr anzeigen"), zählt nicht mit – nur spontane, durch Nachladen ausgelöste Sprünge.

Schwellenwerte

Wert	Bewertung
≤ 0,1	Gut
0,1 – 0,25	Verbesserung erforderlich
> 0,25	Schlecht

Der Wert ist dimensionslos und kombiniert den Anteil des verschobenen Bildschirminhalts mit der Distanz der Verschiebung.

Was CLS beeinflusst

• Bilder ohne width- und height-Attribute, weil der Platz vor dem Laden nicht reserviert ist
• Spät geladene Werbeanzeigen, die nachträglich Platz einnehmen
• Web Fonts, deren Fallback eine andere Höhe hat (FOIT/FOUT)
• Banner und Notifications, die plötzlich am oberen Rand erscheinen
• Dynamisch eingefügte Inhalte ohne reservierten Platz

Schnelle Hebel für CLS

1. Bilder immer mit width und height ausliefern (oder CSS aspect-ratio)
2. Platz für Werbung reservieren mit fester Höhe oder Min-Höhe
3. font-display: optional oder swap mit Size-Adjust-Werten
4. Cookie-Banner bereits beim ersten Rendering einbinden
5. Skeleton-Loader statt leerer Container, die später aufpoppen

Field Data vs. Lab Data

Bei den Core Web Vitals trennt Google zwei Datenquellen, die oft auseinanderlaufen:

Lab Data (Laborwerte)

Synthetische Messungen unter kontrollierten Bedingungen – etwa von Tools wie Lighthouse oder PageSpeed Insights (Lab-Tab). Vorteil: reproduzierbar, vergleichbar, ideal für Tests vor dem Deployment. Nachteil: bildet echte Nutzerbedingungen (Netzwerk, Gerät, Standort) nur näherungsweise ab.

Field Data (Felddaten)

Echte Messdaten von echten Nutzern – aus dem Chrome User Experience Report (CrUX). Diese Werte fließen in das Google-Ranking ein und werden auf einem rollierenden 28-Tage-Fenster aggregiert. Vorteil: spiegelt die reale Nutzererfahrung. Nachteil: Änderungen werden erst nach Wochen sichtbar.

Wichtig: Eine Seite kann im Lab grün und im Feld rot sein – etwa weil viele Nutzer langsame Mobilgeräte oder schwache Netze haben. Das Feld ist das, was zählt.

Wie misst man Core Web Vitals?

Mehrere Tools liefern Werte – jedes mit Stärken und Schwächen:

• PageSpeed Insights (pagespeed.web.dev): Kombiniert Lab- und Field-Daten, gibt konkrete Empfehlungen
• Search Console → Core Web Vitals-Bericht: zeigt Field-Daten gruppiert nach URLs
• Chrome DevTools → Performance- und Lighthouse-Tab: Lab-Messungen während der Entwicklung
• web-vitals JavaScript-Bibliothek: misst echte Werte direkt in der Seite, sendet sie an eigene Analytics
• CrUX Dashboard (BigQuery / Looker Studio): historische Daten für tiefergehende Analysen

Für laufendes Monitoring lohnt sich eine Kombination: Lighthouse in der CI für Frühwarnung bei Deploys, Search Console für die offizielle Sicht und web-vitals.js für eigene Analytics in Echtzeit.

Core Web Vitals und SEO-Ranking

Google hat die Page Experience Signals 2021 zum Ranking-Faktor gemacht, gleichzeitig aber betont: Inhalt schlägt Performance. Eine fachlich überlegene Seite mit schlechten Core Web Vitals rankt weiter über einer dünnen Seite mit perfekten Werten.

Trotzdem ist der Effekt real, vor allem in zwei Konstellationen:

• Tiebreaker bei vergleichbarem Inhalt: Wenn mehrere Seiten ähnlich gut zur Suchanfrage passen, gewinnt die mit besserer Performance
• Mobile Suche: Auf Smartphones zählt die Performance stärker, weil viele Nutzer mit beschränkter Bandbreite und Rechenleistung surfen

Indirekt sind die Effekte größer als der direkte Ranking-Boost vermuten lässt: Schnellere Seiten haben niedrigere Absprungraten, höhere Verweildauer und bessere Konversionsraten – Signale, die Google ebenfalls beobachtet.

Häufige Fehler bei Core Web Vitals

Nur Lab-Werte optimieren

Eine Seite, die in Lighthouse 100/100 erreicht, im Feld aber rote Werte hat, ist nicht „grün". Das Feld ist die offizielle Bewertungsgrundlage – wer nur Lighthouse jagt, übersieht die echten Probleme.

Fehlende Bildmaße

Bilder ohne width/height oder ohne aspect-ratio sind der mit Abstand häufigste CLS-Treiber. Diese Werte gehören zur Pflichtausstattung jedes <img>-Tags.

Schwere Third-Party-Skripte

Marketing-Tracking, Chatbots, A/B-Test-Tools und Ad-Networks können den INP-Wert schon im Alleingang in den Keller ziehen. Jedes externe Skript braucht eine Begründung – und einen Plan, wie es minimal-invasiv geladen wird.

Hero-Bilder ohne Priorisierung

Wenn das LCP-Element ein Bild ist, sollte es mit fetchpriority="high" markiert sein und nicht mit loading="lazy" versehen werden. Lazy Loading auf dem Hauptbild ist einer der häufigsten LCP-Killer.

Optimierung nach Bauchgefühl

Ohne Messdaten weiß niemand, wo das Problem liegt. Bevor optimiert wird, sollte klar sein: Welche Metrik ist rot, an welchen URLs, auf welchem Gerätetyp? Erst dann lohnt sich die technische Arbeit.

Einmal-Optimierung statt Monitoring

Core Web Vitals sind ein bewegliches Ziel. Jedes neue Skript, jedes neue Bild, jede neue Banner-Implementierung kann die Werte verschlechtern. Ein dauerhaftes Monitoring (etwa in der CI oder als Echtzeit-Erfassung) verhindert, dass Verbesserungen mit der Zeit wieder verschwinden.

Zusammenspiel mit anderen SEO-Faktoren

Core Web Vitals stehen nicht isoliert. Sie wirken zusammen mit:

• Bildoptimierung: Bilder sind oft der größte LCP-Treiber – moderne Formate und Lazy Loading wirken direkt auf die Werte
• HTML-Qualität: Sauberes, schlankes HTML lädt schneller und parst zuverlässiger
• Viewport-Konfiguration: Eine korrekte viewport-Meta-Angabe ist Voraussetzung dafür, dass die mobile Performance überhaupt sinnvoll gemessen wird
• Strukturierte Daten: Beeinflussen die Werte nicht direkt, aber gemeinsam mit guten Core Web Vitals entstehen besser klickbare Rich Results

Wer eine Webseite als System versteht – Inhalt, Technik, Performance, Struktur – erzielt nachhaltigere Ergebnisse als jemand, der einzelne Werte isoliert jagt.