Core Web Vitals: Der vollständige Leitfaden 2026

Core Web Vitals (CWV) sind Googles Metriken für das tatsächliche Nutzererlebnis: Ladegeschwindigkeit, Reaktionsfähigkeit der Oberfläche und visuelle Stabilität. Seit Mai 2021 gehören sie zur Page Experience und fließen in das Ranking ein.

Alle drei Metriken werden pro URL bewertet – gute Werte auf der Startseite helfen den Produktseiten nicht. Google bezieht die Daten aus dem Chrome UX Report (echte Nutzer), nicht aus Laborsimulationen.

zoom_in

Was Core Web Vitals sind

Geschichte: von FID zu INP

Google hat Core Web Vitals 2020 mit drei Metriken eingeführt: LCP, FID (First Input Delay) und CLS. FID maß die Verzögerung beim ersten Tippen. Das war wertvoll, erfasste aber nur einen Teil der Interaktivität einer Seite.

LCP – Largest Contentful Paint

LCP erfasst den Zeitpunkt, zu dem der größte sichtbare Inhaltsblock der Seite vollständig gezeichnet ist. Typischerweise ist das ein Hero-Bild, ein Titelbild eines Artikels oder eine große H1-Überschrift.

Häufige Ursachen für einen langsamen LCP

• Langsame TTFB (Server, CDN, fehlendes Caching) – verantwortlich für bis zu 40 % der LCP-Zeit
• Hero-Bild nicht priorisiert: fetchpriority="high" fehlt
• Hero-Bild nicht vorab geladen (<link rel="preload">)
• Render-blockierendes CSS/JS verzögert die erste Darstellung
• Bilder zu groß: kein WebP/AVIF, kein srcset
• LCP-Element hängt an JS-Rendering (React SSR ist zum Zeitpunkt des LCP noch nicht abgeschlossen)

<!-- Prioritise the LCP image -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

<img
  src="/hero.webp"
  alt="Hero"
  fetchpriority="high"
  loading="eager"
  decoding="async"
  width="1280"
  height="720"
/>

INP – Interaction to Next Paint

INP misst die Verzögerung von einer Nutzerinteraktion (Klick, Tastendruck, Tippen) bis zur nächsten sichtbaren Darstellung der Seite. Anders als FID erfasst INP alle Interaktionen während der Sitzung und nutzt den schlechtesten Fall (mit bereinigten Ausreißern).

Was den INP verschlechtert

• Long Tasks über 50 ms blockieren den Hauptthread – der Browser kann Eingaben nicht verarbeiten
• Schwere Event-Handler: synchrones setState in React, massenhafte DOM-Updates
• Kein scheduler.yield() und kein setTimeout(0), um lange Tasks aufzuteilen
• Skripte von Drittanbietern (Chat, Werbung, Analytics) belegen den Hauptthread
• JavaScript-gesteuerte Animationen statt CSS-transform/opacity

// Breaking up a Long Task with scheduler.yield()
async function processLargeList(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    // Yield to the main thread every 50 items
    if (i % 50 === 0) {
      await scheduler.yield();
    }
  }
}

CLS – Cumulative Layout Shift

CLS ist eine einheitenlose Kennzahl für die gesamte unerwartete Verschiebung von Seitenelementen. Formel: Anteil der Auswirkung × Anteil der Distanz. Die Verschiebung eines gedrückten Buttons zählt nicht – nur Elemente, die ohne Nutzeraktion verrutschen.

Häufige Ursachen für CLS

• Bilder ohne Attribute width und height – der Browser kennt die Größe vor dem Laden nicht
• Webschriften ohne font-display: optional oder swap – FOUT verschiebt den Text
• Dynamisch eingeblendete Banner und Cookie-Hinweise oben auf der Seite
• CSS-Animationen, die top/left/margin statt transform ändern
• Werbeanzeigen ohne reservierten Platz (min-height am Container)

/* Reserve space for an ad slot */
.ad-container {
  min-height: 250px;
  width: 100%;
}

/* Animation without CLS: transform and opacity only */
.card:hover {
  transform: translateY(-4px);
  /* Wrong: margin-top: -4px — this shifts layout */
}

Auswirkung auf Rankings

Google hat bestätigt: CWV gehören zu den Page-Experience-Signalen, die in das Ranking einfließen. Sie wirken aber als Tiebreaker, nicht als wichtigster Faktor. Eine Seite mit starkem Inhalt und schlechten CWV rankt vor einer Seite mit guten CWV und schwachem Inhalt.

Der indirekte Effekt wiegt schwerer: Schnelle Seiten senken die Absprungrate und erhöhen die Sitzungstiefe und die Conversions. Der wirtschaftliche Nutzen von CWV ist stärker als der SEO-Nutzen. Amazon stellte fest: +100 ms bei LCP entsprechen −1 % Umsatz.

So messen Sie CWV

Es gibt zwei Arten von Daten: Labordaten (Simulation – Lighthouse, WebPageTest) und Felddaten (echte Nutzer – CrUX, GSC). Google rankt auf Basis der Felddaten. Labordaten dienen der Diagnose.

Diagnosetools

// web-vitals v4 — collect real CWV
import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics({ name, value, id }) {
  // Send to GA4
  gtag('event', name, {
    value: Math.round(name === 'CLS' ? value * 1000 : value),
    metric_id: id,
    metric_delta: value,
  });
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Checkliste zur Optimierung

zoom_in

LCP

• fetchpriority="high" setzen und loading="lazy" vom Hero-Bild entfernen
• <link rel="preload" as="image"> für das Hero-Bild im <head> ergänzen
• Bilder in WebP oder AVIF umwandeln, srcset konfigurieren
• TTFB auf ≤ 800 ms senken: CDN, Caching, Edge SSR
• Render-blockierende Skripte aus dem <head> entfernen (async/defer/module)
• Cache-Control: max-age=31536000 für statische Assets setzen

INP

• Long Tasks in den Chrome DevTools prüfen: Performance → Main Thread
• Tasks über 50 ms mit scheduler.yield() oder setTimeout(0) aufteilen
• Handler für input und scroll entprellen (16–100 ms)
• React optimieren: useMemo, useCallback, React.memo, Virtualisierung von Listen
• Skripte von Drittanbietern in Web Worker auslagern oder erst nach dem LCP laden
• CSS-Animationen nur über transform und opacity umsetzen

CLS

• width und height bei allen <img>-Elementen setzen – der Browser reserviert dann Platz
• aspect-ratio für Container mit unbekannten Maßen verwenden
• font-display: optional für kritische Schriften konfigurieren
• min-height für Werbeflächen und dynamische Inhalte reservieren
• Hinweise (Cookie, Banner) unten statt oben auf der Seite platzieren
• FOUT prüfen: Schriften ohne Fallback verschieben den Text beim Laden