Core Web Vitals

Core Web Vitals machen Ladezeit, visuelle Stabilität und Reaktionsfähigkeit aus Sicht realer Nutzung messbar.

Googles Messgrößen für die Nutzererfahrung einer Webseite – bestehend aus Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) und Interaction to Next Paint (INP).

Einsteiger2 Min Lesezeit

Erklärung starten

Auf einen Blick

3 Punkte

  1. LCP (Largest Contentful Paint): Wie schnell lädt der größte sichtbare Inhalt? Ziel: unter 2,5 Sekunden
  2. CLS (Cumulative Layout Shift): Wie stabil ist das Layout? Ziel: unter 0,1
  3. INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Eingaben? Ziel: unter 200ms

Sofortantwort

Core Web Vitals einfach erklärt

Googles drei Kernmetriken für Ladezeit, visuelle Stabilität und Interaktivität.

Kurz gesagt
LCP (Largest Contentful Paint): Wie schnell lädt der größte sichtbare Inhalt? Ziel: unter 2,5 Sekunden
Typischer Einsatz
SEO-Ranking, Conversion-Optimierung, Performance-Monitoring
Wichtig zu wissen
INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Eingaben? Ziel: unter 200ms

Core Web Vitals im Überblick

Google hat drei Metriken definiert, die messen, wie gut sich eine Webseite für echte Nutzer anfühlt. Diese Core Web Vitals sind seit 2021 ein offizieller Ranking-Faktor – schlechte Werte können Rankings kosten, gute Werte sind ein Wettbewerbsvorteil.

Die drei Metriken:

MetrikMisstGutVerbesserungswürdigSchlecht
LCPLadezeit des größten Elements< 2,5s2,5–4s> 4s
CLSVisuelle Stabilität< 0,10,1–0,25> 0,25
INPReaktionszeit auf Eingaben< 200ms200–500ms> 500ms

Hinweis: INP hat im März 2024 FID (First Input Delay) als offiziellen Core Web Vital abgelöst. FID maß nur die erste Interaktion – INP misst alle Interaktionen während der gesamten Seitennutzung.

Weitere wichtige Metriken (nicht Core, aber relevant)

  • TTFB (Time to First Byte): Wie schnell antwortet der Server? Ziel: < 800ms
  • FCP (First Contentful Paint): Wann erscheint das erste Element? Ziel: < 1,8s
  • TBT (Total Blocking Time): Wie lange blockiert JS den Main Thread? Ziel: < 200ms

Technisch betrachtet

LCP optimieren

Das LCP-Element ist meist ein Hero-Bild oder ein großer Textblock. Der häufigste Fehler: Das Bild wird zu spät entdeckt, weil es im CSS oder per JavaScript geladen wird.

<!-- Preload das LCP-Element (Hero-Bild) – Browser entdeckt es sofort -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

<!-- Bild mit korrekten Dimensionen – verhindert Layout Shift -->
<img
  src="/hero.webp"
  width="1200"
  height="600"
  alt="Hero"
  loading="eager"
  fetchpriority="high"
  decoding="async"
>

LCP-Checkliste:

  • Server-Response-Zeit (TTFB) unter 600ms
  • Kein Render-Blocking CSS/JS vor dem LCP-Element
  • Bild in WebP oder AVIF, richtig dimensioniert
  • CDN nutzen für statische Assets
  • fetchpriority="high" für das LCP-Bild

CLS vermeiden

/* Immer Dimensionen für Bilder und Videos setzen */
img, video {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

/* Platzhalter für Ads/Embeds reservieren */
.ad-slot {
  min-height: 250px;
  contain: layout;
}

/* Webfonts: font-display: optional verhindert FOUT */
@font-face {
  font-family: 'MyFont';
  src: url('/fonts/myfont.woff2') format('woff2');
  font-display: optional;
}

Häufige CLS-Ursachen:

  • Bilder ohne width/height-Attribute
  • Webfonts die beim Laden springen (FOUT)
  • Dynamisch eingefügte Banner oder Cookie-Hinweise über bestehendem Content
  • Lazy-geladene Inhalte ohne Platzhalter

INP optimieren

INP misst die Latenz von Klicks, Tastatureingaben und Taps. Hauptursache für schlechten INP: langer JavaScript-Task blockiert den Main Thread.

// Schlechter INP: Alles synchron im Click-Handler
button.addEventListener('click', () => {
  const result = heavyComputation(); // Blockiert 500ms
  updateUI(result);
});

// Besser: Aufteilen mit scheduler.yield()
button.addEventListener('click', async () => {
  updateUI('Wird berechnet...');
  await scheduler.yield(); // Main Thread freigeben
  const result = heavyComputation();
  updateUI(result);
});

Alle Metriken messen und reporten

import { onLCP, onCLS, onINP, onFCP, onTTFB } from 'web-vitals';

function sendToAnalytics({ name, value, rating, id }) {
  // An eigenes Analytics oder Google Analytics senden
  gtag('event', name, {
    value: Math.round(name === 'CLS' ? value * 1000 : value),
    metric_id: id,
    metric_rating: rating,  // 'good' | 'needs-improvement' | 'poor'
  });
}

onLCP(sendToAnalytics);
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onFCP(sendToAnalytics);
onTTFB(sendToAnalytics);

CI-Integration mit Lighthouse

# .github/workflows/lighthouse.yml
- name: Lighthouse CI
  uses: treosh/lighthouse-ci-action@v10
  with:
    urls: |
      https://www.example.com/
      https://www.example.com/blog/
    budgetPath: ./lighthouse-budget.json
    uploadArtifacts: true

# lighthouse-budget.json
[{
  "path": "/*",
  "timings": [
    { "metric": "largest-contentful-paint", "budget": 2500 },
    { "metric": "cumulative-layout-shift",  "budget": 100 },
    { "metric": "total-blocking-time",      "budget": 200 }
  ]
}]

Häufige Ursachen und Lösungen

ProblemHäufigste UrsacheLösung
Schlechter LCPHero-Bild nicht preloaded<link rel="preload"> + fetchpriority
Hoher CLSBilder ohne Dimensionenwidth/height im HTML
Schlechter INPLanger JS-Task im Click-Handlerscheduler.yield(), Web Workers
Schlechter TTFBLangsamer Server / kein CDNCDN, Edge-Caching, Server-Optimierung

Schritt für Schritt

Web-Performance gezielt verbessern

Gute Werte entstehen nicht durch isolierte Tricks. Reale Nutzung, Engpassanalyse und ein erneuter Vergleich zeigen, welche Änderung wirklich hilft.

  1. Nutzung messen

    Messung

    Felddaten und kontrollierte Tests zeigen, wo Ladezeit, visuelle Verschiebungen oder Eingaben für Menschen problematisch werden.

    reale nutzung + lab test -> ausgangspunkt
  2. Größten Engpass finden

    Diagnose

    Das Team trennt etwa langsame Inhalte, blockierende Skripte, fehlende Platzhalter und teure Interaktionen.

    metriken -> ursache im lade oder interaktionspfad
  3. Gezielt verbessern

    Maßnahme

    Bilder, Auslieferung, Layoutreserven und JavaScript werden nur dort verändert, wo sie den gemessenen Engpass beeinflussen.

    engpass -> gezielte optimierung
  4. Nach Release beobachten

    Nachweis

    Die Wirkung wird erneut mit realen Daten geprüft, damit sich Verbesserungen nicht auf andere Geräte oder Wege negativ auswirken.

    release -> felddaten -> weiter lernen

Konkretes Beispiel

Ein springendes Seitenlayout stabilisieren

Beim Laden einer Seite verschieben sich Inhalte, weil Medien und Einbettungen zu spät Platz erhalten.

Nur die Ladezeit prüfen

Die Seite wirkt schnell, aber Menschen klicken versehentlich auf verschobene Elemente oder verlieren ihre Leseposition.

Layoutstabilität gezielt messen

Reservierte Größen und stabile Ladebereiche senken die Verschiebungen. Ein erneuter Test bestätigt die Wirkung auf unterschiedlichen Geräten.

Eine schnelle Seite ist nur dann gut, wenn sie auch stabil erscheint und auf Eingaben verlässlich reagiert.

Einordnung

Vorteile und Grenzen

Das spricht dafür

  • Nutzerzentrierte Sicht: Die Metriken verbinden technische Ursachen mit spürbarer Lade- und Bedienqualität.
  • Klare Priorisierung: LCP, CLS und INP helfen, große Probleme im Lade- und Interaktionspfad zuerst zu adressieren.
  • Regressionsschutz: Wiederholte Messungen machen sichtbar, wenn neue Releases die Erfahrung verschlechtern.
  • Gemeinsame Sprache: Produkt, Design und Entwicklung können über konkrete Wirkung statt über gefühlte Geschwindigkeit sprechen.

Das solltest du beachten

  • Einzelwerte erklären nicht alles: Gute Metriken ersetzen keine Prüfung von Inhalt, Aufgabenverständnis und Accessibility.
  • Felddaten brauchen Zeit: Neue reale Messwerte entstehen erst, nachdem Menschen die Seite tatsächlich genutzt haben.
  • Optimierung kann Zielkonflikte erzeugen: Weniger JavaScript oder Bilder darf zentrale Funktion und Verständlichkeit nicht beschädigen.
  • Kontext zählt: Geräte, Netze und Nutzerwege unterscheiden sich, daher brauchen Werte eine segmentierte Einordnung.
Vertiefung · für Fortgeschrittene

Die drei Sichtweisen auf Seitenerlebnis

Die Kennzahlen betrachten, wann Hauptinhalt sichtbar wird, ob das Layout stabil bleibt und wie schnell Interaktionen reagieren.

Wissenskarte

Laden, Stabilität und Interaktion messen

Erst die Verbindung aus Messung, Ursachenanalyse und wiederholter Beobachtung macht Performance-Optimierung dauerhaft wirksam. Core Web Vitals gliedert sich in: LCP, CLS, INP, Felddaten, Labordaten, Release-Monitoring.

01Einsatzbereiche

Wann ist Core Web Vitals sinnvoll?

Geeignet für

  • SEO-RankingGoogle nutzt Core Web Vitals als Ranking-Faktor – schlechte Werte können Rankings kosten
  • Conversion-OptimierungLadezeit wirkt auf die Abschlussquote – LCP ist der Wert, der die wahrgenommene Ladezeit abbildet
  • Performance-MonitoringKontinuierliche Überwachung nach Deployments, um Regressionen früh zu erkennen

↑ Inhalt

02Werkzeuge

Womit Core Web Vitals umgesetzt wird

↑ Inhalt

Merksatz

Core Web Vitals sind wie der TÜV für Webseiten

LCP prüft, ob die Seite schnell lädt (Motor), CLS prüft, ob nichts unerwartet springt (Fahrwerk), INP prüft, ob Bedienelemente reagieren (Lenkung). Besteht eine Seite alle drei Tests, gilt sie als fahrbereit für Nutzer.

  1. LCP (Largest Contentful Paint): Wie schnell lädt der größte sichtbare Inhalt? Ziel: unter 2,5 Sekunden
  2. CLS (Cumulative Layout Shift): Wie stabil ist das Layout? Ziel: unter 0,1
  3. INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Eingaben? Ziel: unter 200ms

04Redaktion

Herkunft und Stand

Redaktion und Aktualität

Ebenex RedaktionRedaktion

Veröffentlicht
Aktualisiert

Dieses Feld entwickelt sich schnell. Oben stehen Veröffentlichung und letzte Änderung; ein Prüfdatum kommt dazu, sobald die Erklärung nach ihrer letzten Änderung geprüft wurde.

↑ Inhalt

05FAQ

Häufige Fragen zu Core Web Vitals

Wie verbessere ich meinen LCP-Wert?

Häufigste Ursachen für schlechten LCP: Langsamer Server (TTFB optimieren), nicht optimierte Bilder (WebP, richtige Größe, Preload), blockierendes JavaScript/CSS, fehlende CDN-Nutzung. Das größte Element ist meist ein Hero-Bild oder ein großer Textblock.

Was verursacht einen hohen CLS-Wert?

Bilder ohne definierte Größe (width/height im HTML), Ads oder Embeds die nachgeladen werden, Webfonts die beim Laden springen (FOUT), dynamisch eingefügte Inhalte über bestehenden Inhalten.

Was ist der Unterschied zwischen Lab-Daten und Field-Daten?

Lab-Daten (Lighthouse, PageSpeed): Kontrollierte Messung in einer simulierten Umgebung – gut für Debugging. Field-Daten (Chrome User Experience Report): Echte Messungen von echten Nutzern – relevant für Google-Ranking. Beide sind wichtig, aber Field-Daten entscheiden über das SEO-Ranking.

↑ Inhalt

06Weiterlernen

Was möchtest du als Nächstes verstehen?

  • Grundlage nachholen

    Content Delivery Network

    Ein Netzwerk von Servern liefert Inhalte schnell aus.

  • Technisch vertiefen

    Caching

    Zwischenspeichern von Daten zur Beschleunigung von Anfragen.

↑ Inhalt