Core Web Vitals 2026: INP, LCP, CLS verstehen und optimieren

47% aller deutschen Websites verfehlen Googles Core Web Vitals-Schwellwerte. Seit INP (Interaction to Next Paint) im März 2024 FID ersetzt hat, sind die Anforderungen strenger geworden. Dieser Guide erklärt alle drei Metriken, zeigt Messmethoden und gibt konkrete Optimierungsschritte mit Code-Beispielen.

47%

Websites scheitern

200ms

INP Schwellwert

2.5s

LCP Zielwert

0.1

CLS Maximum

Inhaltsverzeichnis

Was sind Core Web Vitals?

Core Web Vitals sind Googles offizielle Metriken für die User Experience einer Website. Sie messen drei kritische Aspekte der Nutzererfahrung:

INP

Interaction to Next Paint - misst die Reaktionsfähigkeit auf Nutzerinteraktionen

Gut: ≤ 200ms

LCP

Largest Contentful Paint - misst die Ladezeit des größten sichtbaren Elements

Gut: ≤ 2.5s

CLS

Cumulative Layout Shift - misst unerwartete Layout-Verschiebungen

Gut: ≤ 0.1

Warum sind Core Web Vitals so wichtig?

SEO-Ranking: Core Web Vitals sind seit 2021 ein offizieller Google Ranking-Faktor
User Experience: Schlechte Werte = höhere Absprungrate, weniger Conversions
Mobile-First: Google bewertet primär die mobile Performance
Konkurrenz: Bei gleichwertigen Inhalten gewinnt die schnellere Seite

Metrik	Gut	Verbesserungsbedarf	Schlecht
INP	≤ 200ms	200-500ms	> 500ms
LCP	≤ 2.5s	2.5-4.0s	> 4.0s
CLS	≤ 0.1	0.1-0.25	> 0.25

INP: Die neue Metrik seit März 2024

Wichtige Änderung 2024

Am 12. März 2024 hat Google INP (Interaction to Next Paint) als offizielle Core Web Vital eingeführt und FID (First Input Delay) ersetzt. INP ist deutlich strenger und misst die gesamte Interaktivität, nicht nur die erste Eingabe.

Was misst INP genau?

INP misst die Reaktionszeit von der Nutzerinteraktion (Klick, Tap, Tastendruck) bis zum visuellen Feedback. Anders als FID, das nur die erste Interaktion mass, erfasst INP alle Interaktionen während der gesamten Session.

FID (veraltet)

✗ Nur erste Interaktion gemessen
✗ Input Delay, nicht Processing + Paint
✗ Leicht zu optimieren, aber nicht aussagekräftig
✗ Nutzer-Erfahrung nicht vollständig abgebildet

INP (aktuell)

✓ Alle Interaktionen gemessen (75. Perzentil)
✓ Vollständiger Zyklus: Input + Processing + Paint
✓ Echte Nutzer-Erfahrung abgebildet
✓ Realistischere Bewertung der Interaktivität

INP Optimierungstechniken

1. JavaScript-Tasks aufbrechen

Lange JavaScript-Tasks blockieren den Main Thread. Teilen Sie große Funktionen in kleinere Chunks auf.

// SCHLECHT: Ein langer Task blockiert den Main Thread
function processLargeArray(items) {
  items.forEach(item => heavyComputation(item));
}

// GUT: Tasks mit requestIdleCallback aufbrechen
function processLargeArrayOptimized(items) {
  let index = 0;

  function processChunk(deadline) {
    while (index < items.length && deadline.timeRemaining() > 0) {
      heavyComputation(items[index]);
      index++;
    }

    if (index < items.length) {
      requestIdleCallback(processChunk);
    }
  }

  requestIdleCallback(processChunk);
}

2. Event Listener optimieren

Verwenden Sie passive Event Listener und debounce/throttle für scroll/resize Events.

// SCHLECHT: Blockierender Scroll-Handler
document.addEventListener('scroll', handleScroll);

// GUT: Passiver Listener + Throttling
document.addEventListener('scroll', throttle(handleScroll, 100), { passive: true });

function throttle(func, limit) {
  let inThrottle;
  return function(...args) {
    if (!inThrottle) {
      func.apply(this, args);
      inThrottle = true;
      setTimeout(() => inThrottle = false, limit);
    }
  }
}

3. Third-Party Scripts verzögern

Laden Sie Analytics, Chat-Widgets und Ads erst nach der Interaktion oder mit Verzögerung.

// Erst laden, wenn Nutzer interagiert oder nach 5 Sekunden
const loadThirdParty = () => {
  if (window.thirdPartyLoaded) return;
  window.thirdPartyLoaded = true;

  const script = document.createElement('script');
  script.src = 'https://third-party.example.com/widget.js';
  document.head.appendChild(script);
};

// Bei erster Interaktion
['mousedown', 'touchstart', 'keydown'].forEach(event => {
  document.addEventListener(event, loadThirdParty, { once: true });
});

// Oder nach Timeout
setTimeout(loadThirdParty, 5000);

LCP: Largest Contentful Paint optimieren

LCP misst, wie lange es dauert, bis das größte sichtbare Element im Viewport gerendert wird. Das ist typischerweise ein Hero-Bild, eine große Überschrift oder ein Video-Poster.

LCP-relevante Elemente:

• <img> Bilder
• <image> innerhalb SVG
• <video> Poster-Bilder
• Elemente mit background-image
• Block-Level Textelemente (h1, p, etc.)
• <svg> Grafiken

Die 5 wichtigsten LCP-Optimierungen

1. LCP-Element preloaden

Laden Sie das LCP-Element so früh wie möglich mit einem preload Hint.

<!-- Im <head> - VOR anderen Ressourcen -->
<link
  rel="preload"
  as="image"
  href="/hero-image.webp"
  fetchpriority="high"
/>

<!-- Für responsive Bilder -->
<link
  rel="preload"
  as="image"
  href="/hero-mobile.webp"
  media="(max-width: 768px)"
  fetchpriority="high"
/>

2. Optimierte Bildformate verwenden

Verwenden Sie moderne Bildformate und responsive Images mit srcset.

<picture>
  <!-- AVIF: Beste Kompression, limitierter Support -->
  <source
    type="image/avif"
    srcset="
      /hero-400.avif 400w,
      /hero-800.avif 800w,
      /hero-1200.avif 1200w
    "
    sizes="(max-width: 768px) 100vw, 50vw"
  />
  <!-- WebP: Gute Kompression, breiter Support -->
  <source
    type="image/webp"
    srcset="
      /hero-400.webp 400w,
      /hero-800.webp 800w,
      /hero-1200.webp 1200w
    "
    sizes="(max-width: 768px) 100vw, 50vw"
  />
  <!-- Fallback für alte Browser -->
  <img
    src="/hero-800.jpg"
    alt="Hero"
    width="1200"
    height="600"
    loading="eager"
    fetchpriority="high"
    decoding="async"
  />
</picture>

3. Server Response Time (TTFB) optimieren

Die Zeit bis zum ersten Byte beeinflusst direkt LCP. Optimieren Sie Backend und Hosting.

• CDN verwenden: Cloudflare, Vercel Edge, AWS CloudFront
• Server-Side Caching: Redis, Varnish, oder Edge Caching
• Datenbank optimieren: Indexe, Query-Optimierung
• HTTP/2 oder HTTP/3: Multiplexing für parallele Requests
• Static Generation: Astro, Next.js SSG statt SSR

4. Render-Blocking Resources eliminieren

CSS und JavaScript können das Rendern blockieren. Optimieren Sie die Ladereihenfolge.

<!-- Critical CSS inline -->
<style>
  /* Nur das nötige CSS für Above-the-Fold */
  .hero { ... }
  .nav { ... }
</style>

<!-- Rest des CSS asynchron laden -->
<link
  rel="preload"
  href="/styles.css"
  as="style"
  onload="this.onload=null;this.rel='stylesheet'"
/>
<noscript><link rel="stylesheet" href="/styles.css"></noscript>

<!-- JavaScript defer oder async -->
<script src="/app.js" defer></script>

5. Fonts optimieren

Web Fonts können LCP verzögern, wenn Text das LCP-Element ist.

<!-- Font preload mit font-display: swap -->
<link
  rel="preload"
  href="/fonts/inter.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

<style>
  @font-face {
    font-family: 'Inter';
    src: url('/fonts/inter.woff2') format('woff2');
    font-display: swap; /* Zeigt Fallback-Font bis geladen */
    font-weight: 400;
  }
</style>

CLS: Cumulative Layout Shift verstehen

CLS misst, wie stark sich Elemente auf der Seite unerwartet verschieben. Ein hoher CLS-Wert bedeutet eine frustrierende Nutzererfahrung - jeder kennt das: Man will auf einen Button klicken, und plötzlich springt alles.

Die häufigsten CLS-Verursacher:

✗ Bilder ohne width/height Angaben
✗ Ads, Embeds, iFrames ohne reservierten Platz
✗ Dynamisch eingefügter Content
✗ Web Fonts die FOIT/FOUT verursachen

✗ Animationen ohne transform
✗ Cookie Banner die Layout verschieben
✗ Lazy-loaded Content ohne Placeholder
✗ Sticky Header die andere Elemente verschieben

CLS-Optimierung Best Practices

1. Immer Dimensionen für Bilder/Videos angeben

<!-- SCHLECHT: Keine Dimensionen -->
<img src="photo.jpg" alt="Photo">

<!-- GUT: Explizite width/height -->
<img src="photo.jpg" alt="Photo" width="800" height="600">

<!-- AUCH GUT: CSS aspect-ratio -->
<style>
  .responsive-image {
    width: 100%;
    height: auto;
    aspect-ratio: 16 / 9;
    object-fit: cover;
  }
</style>
<img src="photo.jpg" alt="Photo" class="responsive-image">

2. Platzhalter für dynamischen Content

<!-- Reservierter Platz für Werbung -->
<div class="ad-container" style="min-height: 250px;">
  <!-- Ad wird hier geladen -->
</div>

<!-- Skeleton für lazy-loaded Content -->
<div class="card-skeleton" style="height: 300px;">
  <div class="skeleton-image" style="height: 180px;"></div>
  <div class="skeleton-text"></div>
</div>

/* CSS für Skeleton */
.skeleton-image {
  background: linear-gradient(90deg, #1a1a1a 25%, #2a2a2a 50%, #1a1a1a 75%);
  background-size: 200% 100%;
  animation: shimmer 1.5s infinite;
}

@keyframes shimmer {
  0% { background-position: 200% 0; }
  100% { background-position: -200% 0; }
}

3. Animationen mit transform statt position

/* SCHLECHT: Verschiebt das Layout */
.modal-open {
  top: 100px; /* Verursacht Layout Shift */
  left: 50px;
}

/* GUT: Nutzt GPU, kein Layout Shift */
.modal-open {
  transform: translateY(100px) translateX(50px);
}

/* SCHLECHT: Ändert Dimensionen */
.expanded {
  width: 200px;
  height: 300px;
}

/* GUT: Skaliert ohne Layout-Änderung */
.expanded {
  transform: scale(1.2);
}

4. Cookie Banner richtig implementieren

/* SCHLECHT: Banner verschiebt Content */
.cookie-banner {
  position: relative; /* Nimmt Platz im Flow */
}

/* GUT: Fixed oder Sticky, keine Verschiebung */
.cookie-banner {
  position: fixed;
  bottom: 0;
  left: 0;
  right: 0;
  z-index: 9999;
}

/* AUCH GUT: Overlay statt Banner */
.cookie-overlay {
  position: fixed;
  inset: 0;
  display: flex;
  align-items: center;
  justify-content: center;
  background: rgba(0, 0, 0, 0.8);
}

Messung und Monitoring

Es gibt zwei Arten von Core Web Vitals Daten: Field Data (echte Nutzerdaten) und Lab Data (simulierte Tests). Für Google Rankings zählt nur Field Data!

Field Data (RUM)

Echte Nutzerdaten aus dem Chrome User Experience Report (CrUX).

Google Search Console: Core Web Vitals Report
PageSpeed Insights: "Field Data" Sektion
CrUX Dashboard: Historische Daten
web-vitals.js: Eigene RUM-Implementierung

Lab Data (Synthetisch)

Simulierte Tests in kontrollierten Umgebungen.

Lighthouse: In Chrome DevTools integriert
PageSpeed Insights: "Lab Data" Sektion
WebPageTest: Detaillierte Waterfall-Analyse
Debugbear: Continuous Monitoring

web-vitals.js implementieren

// Installation: npm install web-vitals

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

// An Analytics senden
function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    delta: metric.delta,
    id: metric.id,
    rating: metric.rating, // 'good', 'needs-improvement', oder 'poor'
  });

  // Beacon API für zuverlässige Übertragung
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/analytics', body);
  } else {
    fetch('/analytics', { body, method: 'POST', keepalive: true });
  }
}

// Alle Core Web Vitals messen
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
onCLS(sendToAnalytics);

Pro-Tipp: Attribution für Debugging

Verwenden Sie die Attribution-Builds für detaillierte Debug-Informationen:

import { onINP } from 'web-vitals/attribution';

onINP((metric) => {

});

Fortgeschrittene Optimierungsstrategien

Priority Hints für Ressourcen

Mit fetchpriority können Sie dem Browser mitteilen, welche Ressourcen wichtig sind.

<!-- Hero-Bild mit hoher Priorität -->
<img src="hero.jpg" fetchpriority="high" alt="Hero">

<!-- Below-the-fold Bilder mit niedriger Priorität -->
<img src="footer-logo.png" fetchpriority="low" loading="lazy" alt="Logo">

<!-- Scripts -->
<script src="critical.js" fetchpriority="high"></script>
<script src="analytics.js" fetchpriority="low" defer></script>

Speculation Rules API (Chrome 2026)

Prerendering für nahezu instantane Navigationen.

<script is:inline type="speculationrules">
{
  "prerender": [{
    "source": "list",
    "urls": ["/about", "/contact", "/pricing"]
  }],
  "prefetch": [{
    "source": "document",
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

View Transitions API

Flüssige Übergänge zwischen Seiten ohne Layout Shifts.

// In Astro 4.0+
---
// In astro.config.mjs
export default defineConfig({
  experimental: {
    viewTransitions: true
  }
});
---

<!-- In Ihrem Layout -->
<head>
  <ViewTransitions />
</head>

<!-- Animierte Elemente -->
<h1 transition:name="page-title">Seitentitel</h1>
<img transition:name="hero" src="/hero.jpg" />

Scheduler API für JavaScript

Priorisieren Sie JavaScript-Tasks für bessere INP-Werte.

// Hohe Priorität: User-visible Updates
scheduler.postTask(() => {
  updateUI();
}, { priority: 'user-blocking' });

// Niedrige Priorität: Analytics, Logging
scheduler.postTask(() => {
  sendAnalytics();
}, { priority: 'background' });

// Yielding zum Main Thread
async function processItems(items) {
  for (const item of items) {
    processItem(item);
    await scheduler.yield(); // Main Thread freigeben
  }
}

Vollständiges Code-Beispiel: Optimierte Hero Section

Das folgende Beispiel zeigt eine Hero Section, die die Core Web Vitals Best Practices für INP, LCP und CLS umsetzt:

<!-- HTML: Optimierte Hero Section -->
<!DOCTYPE html>
<html lang="de">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <!-- Preconnect für externe Ressourcen -->
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://cdn.example.com" crossorigin>

  <!-- Preload kritischer Ressourcen -->
  <link
    rel="preload"
    as="image"
    href="/hero-mobile.webp"
    media="(max-width: 768px)"
    fetchpriority="high"
  >
  <link
    rel="preload"
    as="image"
    href="/hero-desktop.webp"
    media="(min-width: 769px)"
    fetchpriority="high"
  >
  <link rel="preload" as="font" href="/fonts/inter.woff2" type="font/woff2" crossorigin>

  <!-- Critical CSS inline -->
  <style>
    /* Reset und Critical Styles */
    *, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; }

    @font-face {
      font-family: 'Inter';
      src: url('/fonts/inter.woff2') format('woff2');
      font-display: swap;
    }

    body {
      font-family: 'Inter', system-ui, sans-serif;
      background: #0a0a0a;
      color: #fff;
    }

    /* Hero mit festen Dimensionen für CLS */
    .hero {
      min-height: 100vh;
      display: flex;
      align-items: center;
      position: relative;
      overflow: hidden;
    }

    .hero-image {
      position: absolute;
      inset: 0;
      width: 100%;
      height: 100%;
      object-fit: cover;
    }

    .hero-content {
      position: relative;
      z-index: 1;
      max-width: 1200px;
      margin: 0 auto;
      padding: 2rem;
    }

    /* Animationen mit transform (kein Layout Shift) */
    .hero-title {
      opacity: 0;
      transform: translateY(20px);
      animation: fadeInUp 0.6s ease-out 0.1s forwards;
    }

    @keyframes fadeInUp {
      to { opacity: 1; transform: translateY(0); }
    }

    /* Button mit fester Größe */
    .cta-button {
      display: inline-block;
      padding: 1rem 2rem;
      min-width: 200px;
      text-align: center;
      /* ... weitere Styles */
    }
  </style>
</head>
<body>
  <section class="hero">
    <!-- Hero-Bild mit allen Optimierungen -->
    <picture>
      <source
        type="image/webp"
        media="(max-width: 768px)"
        srcset="/hero-mobile.webp"
      >
      <source
        type="image/webp"
        media="(min-width: 769px)"
        srcset="/hero-desktop.webp"
      >
      <img
        src="/hero-desktop.jpg"
        alt="Hero Image"
        class="hero-image"
        width="1920"
        height="1080"
        fetchpriority="high"
        decoding="async"
      >
    </picture>

    <div class="hero-content">
      <h1 class="hero-title">Ihre Überschrift hier</h1>
      <a href="/contact" class="cta-button">Jetzt starten</a>
    </div>
  </section>

  <!-- Non-critical CSS asynchron -->
  <link rel="stylesheet" href="/styles.css" media="print" onload="this.media='all'">

  <!-- JavaScript defer -->
  <script src="/app.js" defer></script>
</body>
</html>

Häufig gestellte Fragen

Wie lange dauert es, bis Verbesserungen in der Search Console sichtbar sind?

Google verwendet einen 28-Tage gleitenden Durchschnitt von CrUX-Daten. Nach einer Verbesserung dauert es typischerweise 28-30 Tage, bis die neuen Werte vollständig in der Search Console reflektiert werden. Bei größeren Websites kann es etwas schneller gehen, da mehr Nutzerdaten gesammelt werden.

Meine Lab-Daten sind gut, aber Field-Daten schlecht - warum?

Lab-Tests werden unter kontrollierten Bedingungen durchgeführt, während Field-Daten echte Nutzererfahrungen abbilden. Mögliche Gründe: Langsamere Geräte Ihrer Nutzer, schlechte Internetverbindungen (3G/4G), Third-Party Scripts die im Lab nicht geladen werden, oder geografische Unterschiede (Server weit von Nutzern entfernt).

Gilt das 75. Perzentil für alle Metriken?

Ja, Google verwendet das 75. Perzentil für alle Core Web Vitals. Das bedeutet: 75% Ihrer Nutzer müssen die "Gut"-Schwellwerte erreichen, damit die Seite als bestanden gilt. Dies stellt sicher, dass die Mehrheit der Nutzer eine gute Erfahrung hat, nicht nur die mit schnellen Geräten.

Wie wirken sich schlechte Core Web Vitals auf Rankings aus?

Core Web Vitals sind ein Tiebreaker-Signal: Bei gleichwertigem Content gewinnt die schnellere Seite. Content bleibt wichtiger als Performance, aber schlechte CWV können Sie gegenüber Konkurrenten mit ähnlichem Content benachteiligen. In umkampften Nischen kann der Unterschied signifikant sein.

Brauche ich für jede URL gute CWV oder nur für die Domain?

Google bewertet auf URL-Ebene, aber verwendet aggregierte Daten ähnlicher Seiten, wenn nicht genug URL-spezifische Daten vorhanden sind. Bei wenig Traffic wird die Origin-Level (gesamte Domain) Bewertung verwendet. Idealerweise optimieren Sie alle wichtigen Seiten individuell.

Core Web Vitals gezielt verbessern

Core Web Vitals sind kein reines SEO-Thema. Sie messen, wie sich Ihre Website für echte Nutzer anfühlt. Konkrete Auswirkungen gut optimierter Werte:

Bessere Google-Rankings bei technisch gleichwertigem Content
Absprungraten um 20-30% reduziert
Conversion-Rates um 10-25% verbessert
Mobile Nutzer (70%+ des Traffics) zuverlässig bedient
47% der Konkurrenz, die die Schwellwerte verfehlt, klar abgehängt

Messen Sie Ihre aktuellen Werte in der Google Search Console, identifizieren Sie die größten Probleme und arbeiten Sie die Checkliste oben systematisch ab. Field Data im CrUX-Bericht zeigt nach 28-30 Tagen, ob die Verbesserungen greifen.

Quellen & Referenzen

Dieser Artikel basiert auf folgenden verifizierten Quellen:

Dokumentation

1.
Web Vitals - Essential metrics for a healthy site Externe Quelle
Google • 2026
2.
Interaction to Next Paint (INP) - Official Documentation Externe Quelle
Google • 2024
3.
Optimizing Interaction to Next Paint Externe Quelle
Google • 2024
4.
Largest Contentful Paint (LCP) Optimization Guide Externe Quelle
Google • 2024

Forschung

1.
Core Web Vitals Technology Report - HTTP Archive Externe Quelle
HTTP Archive • 2026

Core Web Vitals optimieren lassen?

Wir analysieren Ihre Website, identifizieren die größten Baustellen und setzen die Optimierungen um. Mit messbaren Verbesserungen in der Search Console.

Kostenlose Performance-Analyse

Performance-Services ansehen

Weiterführende Artikel

Verwandter Artikel