Core Web Vitals verbessern: LCP, CLS, INP optimieren — Schritt für Schritt

Die Core Web Vitals sind seit dem Page Experience Update (2021) offizielle Google-Rankingfaktoren. Wer beim LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) und INP (Interaction to Next Paint) schlechte Werte hat, verliert im direkten Wettbewerb gegen Seiten mit ähnlichem Content aber besserer Performance.

In diesem Artikel erkläre ich jeden der drei Metriken im Detail — was er misst, warum er wichtig ist und welche konkreten Maßnahmen den größten Hebel haben. Du bekommst eine priorisierte Schritt-für-Schritt-Anleitung, die du direkt umsetzen kannst.

Kurze Einführung? Lies zuerst Ladezeit als Ranking-Faktor — der Überblicksartikel zum Cluster Performance-SEO. Dieser Artikel hier ist die tiefe Umsetzungsanleitung.

Was sind Core Web Vitals — Kurzübersicht

Google misst die Nutzererfahrung auf Websites mit drei Kernmetriken:

LCP

Largest Contentful Paint

Ladegeschwindigkeit des größten sichtbaren Elements

✓ Gut: < 2,5 Sekunden

⚠ OK: 2,5 – 4,0 s

✗ Schlecht: > 4,0 s

CLS

Cumulative Layout Shift

Visuelle Stabilität — wie stark Elemente beim Laden springen

✓ Gut: < 0,1

⚠ OK: 0,1 – 0,25

✗ Schlecht: > 0,25

INP

Interaction to Next Paint

Reaktionsfähigkeit auf Nutzereingaben (seit März 2024)

✓ Gut: < 200 ms

⚠ OK: 200 – 500 ms

✗ Schlecht: > 500 ms

Google misst diese Werte anhand von echten Nutzerdaten (Chrome User Experience Report, kurz CrUX). Das bedeutet: Labortests in PageSpeed Insights zeigen dir Schätzwerte, aber in die Suchergebnisse fließen die realen Feldwerte ein. Beides im Blick zu haben ist wichtig.

LCP verbessern: Das größte sichtbare Element schneller laden

Der LCP misst, wann das größte sichtbare Element im Viewport vollständig geladen ist. Das ist meistens ein Hero-Bild, ein großes Textblock, ein Video-Poster oder ein Banner. Google möchte, dass dieser Wert unter 2,5 Sekunden bleibt.

Schritt 1: Herausfinden, was das LCP-Element ist

Öffne Chrome DevTools (F12) → Tab "Performance" → Seite neu laden → In der Timeline findest du den LCP-Marker. Klicke darauf, um das Element zu sehen. Alternativ: PageSpeed Insights zeigt dir das LCP-Element direkt mit einem Screenshot.

Die häufigsten LCP-Elemente:

Hero-Bild: Häufigste Ursache für schlechten LCP
Text-Block: Wenn eine Webfont noch nicht geladen ist (FOIT/FOUT)
Video-Poster-Frame: Bei Seiten mit Video im Header
Background-Image via CSS: Schwerer zu optimieren als img-Tags

Schritt 2: Das LCP-Element mit Priorität laden

Das häufigste und wirkungsvollste Fix: Das Hero-Bild bekommt fetchpriority="high" und loading="eager":

<!-- Schlecht: Browser entdeckt Bild zu spät -->
<img src="hero.jpg" loading="lazy" alt="Hero">

<!-- Gut: Browser lädt Bild mit hoher Priorität -->
<img src="hero.webp"
     fetchpriority="high"
     loading="eager"
     width="1200"
     height="600"
     alt="Hero-Bild mit Keyword">

Wichtig: loading="lazy" am Hero-Bild ist ein sehr häufiger Fehler. Lazy Loading ist für Bilder unterhalb des sichtbaren Bereichs gedacht — nicht für das erste Bild auf der Seite.

Schritt 3: Bilder im richtigen Format und Größe ausliefern

WebP ist im Schnitt 25–35% kleiner als JPEG bei gleicher Qualität. AVIF spart nochmals 20% gegenüber WebP, hat aber noch keine vollständige Browser-Unterstützung. Die empfohlene Strategie für 2026:

<picture>
    <source srcset="hero.avif" type="image/avif">
    <source srcset="hero.webp" type="image/webp">
    <img src="hero.jpg" alt="Hero-Bild" width="1200" height="600"
         fetchpriority="high">
</picture>

Außerdem: Nutze srcset und sizes für responsive Bilder, damit der Browser nicht ein 2000px-Bild auf ein 375px-Smartphone lädt:

<img src="hero-800.webp"
     srcset="hero-400.webp 400w,
             hero-800.webp 800w,
             hero-1200.webp 1200w"
     sizes="(max-width: 600px) 100vw,
            (max-width: 1200px) 80vw,
            1200px"
     alt="Beschreibung">

Schritt 4: LCP-Ressource preloaden

Wenn das LCP-Element ein Bild im CSS-Background oder ein Lazy-loaded Image ist, das der Browser zu spät entdeckt, hilft ein Preload-Link im <head>:

<link rel="preload" as="image"
      href="hero.webp"
      fetchpriority="high">

Vorsicht: Preloads nur für das eine LCP-Element setzen. Zu viele Preloads kämpfen um Bandbreite und verschlechtern den LCP.

Schritt 5: Server-Antwortzeit (TTFB) verbessern

Ein schlechter TTFB (Time to First Byte) limitiert den LCP von Anfang an — wenn der Server 1,5 Sekunden braucht, kann der LCP nie unter 2,5 Sekunden fallen. Die wichtigsten Maßnahmen: CDN verwenden, Server-Caching aktivieren und PHP/Node.js optimieren. Mehr dazu im Artikel TTFB verbessern: Server-Antwortzeit optimieren.

CLS verbessern: Layout-Sprünge eliminieren

Der CLS (Cumulative Layout Shift) misst, wie stark Elemente auf der Seite beim Laden springen. Jeder kennt das: Man will auf einen Button klicken, und plötzlich springt das Layout und man klickt auf etwas anderes. Das ist nicht nur nervig — Google bewertet es als schlechte Nutzererfahrung.

Der CLS-Score berechnet sich aus: Impact-Fraction × Distance-Fraction. Ein Element das 50% des Viewports einnimmt und um 25% des Viewports verschoben wird, ergibt einen CLS von 0,125 — bereits im "Needs Improvement"-Bereich.

Häufigste Ursachen für CLS

Bilder ohne Dimensionen: Wenn width und height fehlen, kennt der Browser den Platz erst nach dem Laden
Werbeanzeigen (AdSense): Ads laden asynchron und drücken Content nach unten
Web Fonts (FOUT): Systemschrift wird durch Webfont ersetzt und nimmt anderen Platz ein
Dynamisch injizierter Content: Banner, Cookie-Hinweise, Chat-Widgets die nach dem ersten Rendern erscheinen
CSS-Animationen: Falsch umgesetzte Animationen die top/left statt transform verwenden

Fix 1: Immer Bildgrößen angeben

Die einfachste und wirkungsvollste Maßnahme gegen CLS: Alle Bilder und Videos mit width und height auszeichnen. Der Browser reserviert dann den Platz, bevor das Bild geladen ist:

<!-- Schlecht: Browser kennt Größe nicht -->
<img src="bild.jpg" alt="Beschreibung">

<!-- Gut: Browser reserviert Platz -->
<img src="bild.jpg" alt="Beschreibung" width="800" height="450">

Mit CSS kannst du das Bild trotzdem responsive machen: img { max-width: 100%; height: auto; } — das überschreibt die absoluten Dimensionen visuell, aber der Browser nutzt das Seitenverhältnis für die Platzreservierung.

Fix 2: Ads und Embeds mit Platzhaltern versehen

AdSense und andere Anzeigen sind einer der größten CLS-Verursacher. Reserviere Platz mit einem Min-Height-Wrapper:

/* CSS-Platzhalter für Werbebanner */
.ad-slot {
    min-height: 250px; /* Typische Banner-Höhe */
    background: rgba(0,0,0,0.05);
}

/* Oder mit aspect-ratio für responsive Ads */
.ad-slot-leaderboard {
    aspect-ratio: 728 / 90;
    width: 100%;
    max-width: 728px;
}

Fix 3: Web Fonts mit font-display optimieren

Wenn eine Webfont den Text-Layout ändert, entsteht CLS. font-display: optional verhindert das vollständig — die Systemschrift wird verwendet, wenn die Webfont nicht im ersten Render-Fenster bereit ist:

@font-face {
    font-family: 'MeinFont';
    src: url('font.woff2') format('woff2');
    font-display: optional; /* oder 'swap' mit size-adjust */
    size-adjust: 105%; /* Gleicht Größenunterschiede aus */
}

Google Fonts unterstützt font-display=swap direkt per URL-Parameter: &display=swap. Das ist besser als kein Parameter, aber optional ist für CLS noch besser.

Fix 4: Cookie-Banner und Modals vorbereiten

Cookie-Hinweise die den Content nach unten drücken sind ein CLS-Klassiker. Lösung: Den Cookie-Banner nicht im normalen Dokumentfluss platzieren, sondern als fixed-Position-Element:

.cookie-banner {
    position: fixed;
    bottom: 0;
    left: 0;
    right: 0;
    /* NICHT: position: relative in einem normalen Container */
}

INP verbessern: Schnelle Reaktion auf Nutzereingaben

INP (Interaction to Next Paint) ist seit März 2024 offiziell Core Web Vital und hat FID (First Input Delay) abgelöst. Während FID nur den ersten Klick maß, misst INP die langsamste Interaktion über die gesamte Sitzung. Das macht INP deutlich strenger.

Eine Interaktion umfasst: Klick → JavaScript verarbeitet → DOM-Update → Browser rendert das nächste Frame (Paint). Das alles muss in unter 200ms passieren.

Was INP verlangsamt

Langer JavaScript-Main-Thread: Tasks die länger als 50ms dauern blockieren alle Eingaben
Zu viel JavaScript beim Page Load: Ungenutzte Bibliotheken die alles verlangsamen
Event-Handler ohne Optimierung: Click-Handler die synchron große Mengen DOM-Manipulationen auslösen
Third-Party-Scripts: Analytics, Chat-Widgets, Werbeskripte die den Main Thread blockieren

INP-Diagnose mit Chrome DevTools

So findest du langsame Interaktionen:

Chrome DevTools öffnen → Performance-Tab
Performance Insights Tab (neu in Chrome) nutzen → zeigt INP-Kandidaten direkt
Oder: Chrome Task Manager → "Longest Tasks" in der Timeline suchen
Web Vitals Extension installieren → zeigt INP-Wert in Echtzeit

Fix 1: Lange Tasks aufteilen (Task Chunking)

JavaScript blockiert den Browser-Main-Thread. Tasks die länger als 50ms dauern ("Long Tasks") verhindern, dass der Browser auf Nutzereingaben reagiert. Die Lösung: Lange Berechnungen in kleinere Chunks aufteilen:

// Schlecht: Ein langer synchroner Task
function processLargeArray(items) {
    items.forEach(item => heavyWork(item));
}

// Gut: In Chunks aufteilen mit yielding
async function processInChunks(items, chunkSize = 50) {
    for (let i = 0; i < items.length; i += chunkSize) {
        const chunk = items.slice(i, i + chunkSize);
        chunk.forEach(item => heavyWork(item));

        // Dem Browser Zeit geben zu atmen
        await scheduler.yield(); // Chrome 124+
        // Fallback: await new Promise(r => setTimeout(r, 0));
    }
}

Fix 2: Event-Handler-Arbeit verschieben

Alles was nicht unmittelbar für das visuelle Feedback des Klicks nötig ist, kann nach dem Paint verschoben werden:

button.addEventListener('click', async (event) => {
    // 1. Sofortiges visuelles Feedback (vor dem yield)
    button.classList.add('loading');
    button.textContent = 'Wird verarbeitet...';

    // 2. Main Thread freigeben
    await scheduler.yield();

    // 3. Schwere Arbeit NACH dem Paint
    await doHeavyWork();
    button.classList.remove('loading');
    button.textContent = 'Fertig!';
});

Fix 3: JavaScript-Menge reduzieren

Weniger JavaScript bedeutet weniger Parsing, weniger Kompilierung, weniger Ausführung. Konkrete Maßnahmen:

Code Splitting: Lade JavaScript nur für die aktuelle Seite, nicht für die gesamte App
Tree Shaking: Entferne ungenutzten Code aus Bibliotheken (funktioniert mit Webpack/Rollup/Vite)
Bibliotheken ersetzen: Moment.js (329KB) → date-fns (nur was du brauchst). Lodash → native Array-Methoden
Defer und async: Nicht kritisches JavaScript mit defer oder async laden

Fix 4: Third-Party-Scripts kontrollieren

Chat-Widgets, Hotjar, Intercom und ähnliche Tools sind häufig die Hauptverursacher schlechter INP-Werte. Messe den Einfluss mit Lighthouse + "Block third-party scripts". Wenn der INP sich dramatisch verbessert, hast du den Täter gefunden.

Lösungsansätze: Scripts mit defer laden, Facade-Pattern für Chat-Widgets (erst nach erstem Klick laden), oder den Script-Load auf after first interaction verzögern.

Core Web Vitals messen: Die richtigen Tools

Google PageSpeed Insights (empfohlen)

Das wichtigste Tool: PageSpeed Insights zeigt sowohl Feld-Daten (echte Nutzer aus CrUX) als auch Lab-Daten (Lighthouse-Simulation). Die Feld-Daten sind das, was Google für das Ranking verwendet.

Wichtig: Feld-Daten brauchen ausreichend Traffic. Neue Seiten oder sehr kleine Websites haben oft keine Feld-Daten — dann zählen die Lab-Werte.

Google Search Console — Core Web Vitals Bericht

Der CWV-Bericht in der Google Search Console ist Pflichtlektüre. Er zeigt dir:

Welche URLs "Gut", "Verbesserungsbedarf" oder "Schlecht" sind
Welcher Metrikwert das Problem verursacht
Wie viele URLs betroffen sind
Ob sich die Werte nach deinen Optimierungen verbessert haben (mit Verzögerung von ~28 Tagen)

Chrome DevTools Performance-Tab

Für die technische Ursachenforschung ist Chrome DevTools unersetzlich. Der Performance-Tab zeigt Long Tasks (rot markiert), Rendering-Bottlenecks und welche Scripts den Main Thread blockieren.

Web Vitals Extension

Die kostenlose Chrome Extension von Google zeigt LCP, CLS und INP in Echtzeit beim Surfen auf jeder Website. Ideal für schnelle Tests ohne PageSpeed Insights öffnen zu müssen.

Priorisierung: Wo anfangen?

Du hast begrenzte Zeit. Diese Reihenfolge bringt den größten Impact:

LCP: Hero-Bild optimieren — größter Hebel, oft 30-60% LCP-Verbesserung möglich
CLS: Bildgrößen angeben — 30 Minuten Arbeit, kann CLS auf 0 bringen
LCP: Server-Antwortzeit (TTFB) prüfen — CDN einrichten wenn TTFB > 600ms
CLS: Cookie-Banner auf fixed positionieren — häufig übersehen, große Wirkung
INP: Third-Party-Scripts analysieren — welche kosten wie viel Main Thread?
LCP: Render-Blocking-Ressourcen entfernen — mehr dazu in CSS und JavaScript richtig laden
INP: Code Splitting implementieren — aufwändiger, aber langfristig wichtig

Benchmark: Was sind gute Core Web Vitals für 2026?

Die offiziellen Google-Schwellenwerte haben sich seit 2021 nicht geändert. In der Praxis zeigt die Branchenforschung jedoch, dass die führenden Websites deutlich besser als "Gut" abschneiden:

Metrik	Gut	Verbesserung nötig	Schlecht	Top 10% (Ziel)
LCP	< 2,5 s	2,5 – 4,0 s	> 4,0 s	< 1,2 s
CLS	< 0,1	0,1 – 0,25	> 0,25	< 0,02
INP	< 200 ms	200 – 500 ms	> 500 ms	< 80 ms

Checkliste: Core Web Vitals verbessern

LCP-Checkliste

☐ Hero-Bild mit fetchpriority="high" und loading="eager" auszeichnen
☐ Bilder in WebP/AVIF konvertieren (nicht WebP)
☐ Responsive Bilder mit srcset und sizes implementieren
☐ TTFB prüfen (Ziel: unter 600ms) — CDN einrichten wenn nötig
☐ Render-Blocking CSS/JS im <head> minimieren
☐ Server-seitiges Caching aktivieren
☐ loading="lazy" von Hero-Bild entfernen (falls vorhanden!)

CLS-Checkliste

☐ Alle <img> Tags mit width und height versehen
☐ Alle <video> Tags mit width und height versehen
☐ Ad-Slots mit Min-Height-Platzhalter sichern
☐ Cookie-Banner auf position: fixed setzen
☐ Web Font mit font-display: optional oder swap + size-adjust konfigurieren
☐ CSS-Animationen prüfen: transform statt top/left

INP-Checkliste

☐ Total Blocking Time (TBT) in PageSpeed Insights prüfen
☐ Long Tasks (> 50ms) in Chrome DevTools identifizieren
☐ Third-Party-Scripts mit hohem Main-Thread-Verbrauch deaktivieren/verzögern
☐ JavaScript-Bundle-Größe analysieren (Coverage-Tab in DevTools)
☐ Code Splitting für große Single-Page-Apps implementieren
☐ Event Handler mit scheduler.yield() optimieren

Fazit: Core Web Vitals als kontinuierlicher Prozess

Core Web Vitals verbessern ist kein einmaliges Projekt — es ist ein kontinuierlicher Prozess. Google aktualisiert die Messmethoden (wie der Wechsel von FID zu INP), neue Designelemente können CLS einführen, und wachsender JavaScript-Code kann INP verschlechtern.

Mein Empfehlung: Richte einen monatlichen Check in PageSpeed Insights und Google Search Console ein. 30 Minuten pro Monat reichen, um Rückschritte früh zu erkennen.

Für eine vollständige SEO-Analyse deiner Website — inklusive Core Web Vitals, Meta-Tags, interne Verlinkung und mehr — nutze die kostenlose Analyse auf shift07.ai. Du siehst sofort, wo der größte Optimierungsbedarf besteht.

Im nächsten Artikel dieser Serie geht es um JavaScript-Performance für SEO: Lazy Loading, Code Splitting und Defer — für alle die tiefer in die technische Umsetzung einsteigen wollen.