<EbeneX/>
Web Marketing · Updated 3. März 2026

Core Web Vitals

Definition

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).

Einsteiger 4 Min. Lesezeit EN: Core Web Vitals

Einfach erklärt

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

Technischer Deep Dive

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

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.

LCP (Largest Contentful Paint): Wie schnell lädt der größte sichtbare Inhalt? Ziel: unter 2,5 Sekunden

CLS (Cumulative Layout Shift): Wie stabil ist das Layout? Ziel: unter 0,1

INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Eingaben? Ziel: unter 200ms

SEO-Ranking

Google nutzt Core Web Vitals als Ranking-Faktor – schlechte Werte können Rankings kosten

Conversion-Optimierung

Studien zeigen: Jede Sekunde Ladezeit kostet Conversions – LCP direkt mit Umsatz verknüpft

Performance-Monitoring

Kontinuierliche Überwachung nach Deployments, um Regressionen früh zu erkennen

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.

Dein persönliches Share-Bild für Instagram – 1080×1080px, bereit zum Posten.