Core Web Vitals verbessern: Der Praxis-Guide für schnelle Websites [2026]

Core Web Vitals sind drei Metriken, mit denen Google die Nutzererfahrung deiner Website misst. Seit 2021 sind sie ein offizieller Ranking-Faktor. Seit 2024 hat Google INP (Interaction to Next Paint) als Metrik eingeführt und FID (First Input Delay) ersetzt.

Die Logik dahinter ist simpel: Google will Seiten ranken, die Nutzer nicht frustrieren. Eine Seite die 5 Sekunden lädt, beim Scrollen herumspringt und auf Klicks nicht reagiert — die will niemand. Also misst Google genau das.

| Metrik | Was sie misst | Zielwert | Was Nutzer merken |
| --- | --- | --- | --- |
| LCP (Largest Contentful Paint) | Wie schnell der Hauptinhalt sichtbar ist | < 2,5 Sekunden | Seite fühlt sich schnell an |
| INP (Interaction to Next Paint) | Wie schnell die Seite auf Klicks/Taps reagiert | < 200ms | Buttons reagieren sofort |
| CLS (Cumulative Layout Shift) | Wie stabil das Layout beim Laden ist | < 0,1 | Nichts springt herum |

Takeaway

Core Web Vitals sind kein Bonus-Ranking-Faktor. Sie sind ein Hygiene-Faktor. Wenn deine Werte schlecht sind, verlierst du Rankings an Seiten die technisch besser aufgestellt sind — auch wenn dein Content besser ist.

Bevor du irgendetwas optimierst: Miss erstmal. Es gibt zwei Arten von Daten — und du brauchst beide:

| Datentyp | Tool | Was es zeigt | Wann nutzen |
| --- | --- | --- | --- |
| Field Data (echte Nutzer) | Google Search Console → Core Web Vitals | Was echte Besucher erleben | Für den Gesamtüberblick |
| Field Data | PageSpeed Insights → Abschnitt 'Felddaten' | CrUX-Daten von echten Chrome-Nutzern | Für einzelne URLs |
| Lab Data (simuliert) | PageSpeed Insights → Abschnitt 'Labdaten' | Was ein Testlauf ergibt | Für Diagnose und Debugging |
| Lab Data | Chrome DevTools → Lighthouse | Detaillierte Analyse mit Screenshots | Für technisches Debugging |

1. Öffne die Google Search Console → Nutzerfreundlichkeit → Core Web Vitals
2. Schau dir den Bericht an: Wie viele URLs sind „Schlecht“ (rot), „Verbesserung nötig“ (gelb), „Gut“ (grün)?
3. Für die schlimmsten URLs: Öffne PageSpeed Insights und analysiere die einzelne URL
4. Notiere die aktuellen Werte — das sind deine Baseline-Daten für den Vorher/Nachher-Vergleich

Weiterführende Links: SEO-Audit: Vollständige Performance-Analyse

LCP (Largest Contentful Paint) misst wie lange es dauert bis der größte sichtbare Inhalt geladen ist — meistens ein Hero-Bild oder eine große Überschrift. Zielwert: unter 2,5 Sekunden.

Die häufigsten Ursachen für schlechtes LCP, sortiert nach Impact:

| Problem | Impact | Fix | Aufwand |
| --- | --- | --- | --- |
| Zu große Bilder (nicht komprimiert) | Sehr hoch | WebP/AVIF Format, Komprimierung, richtige Dimensionen | Quick Win (5 Min) |
| Kein Lazy Loading | Hoch | loading='lazy' auf alle Bilder außer dem Hero-Bild | Quick Win (5 Min) |
| Langsamer Server (TTFB > 800ms) | Hoch | Besseres Hosting, CDN, Server-Caching | Deep Fix |
| Render-blockierendes CSS/JS | Mittel-Hoch | Critical CSS inline, Rest defer/async | Deep Fix |
| Keine Font-Optimierung | Mittel | font-display: swap, Fonts preloaden | Quick Win (10 Min) |

Takeaway

Der häufigste LCP-Killer den ich sehe: Ein Hero-Bild das 3MB groß ist weil niemand es komprimiert hat. Komprimierung auf WebP + richtige Dimensionen → LCP halbiert sich. 5 Minuten Arbeit.

Weiterführende Links: web.dev: Optimize LCP

INP (Interaction to Next Paint) ist seit 2024 die neue Metrik für Interaktivität. Sie ersetzt FID und ist DEUTLICH strenger. 43% aller Websites bestehen den INP-Test nicht — es ist die am häufigsten fehlende Core Web Vital.

INP misst wie lange es dauert, bis die Seite auf einen Klick, Tap oder Tastendruck visuell reagiert. Zielwert: unter 200ms.

Warum so viele Websites durchfallen: JavaScript. Jedes Script das den Main Thread blockiert, verzögert die Reaktion auf User-Input.

• Zu viel Third-Party JavaScript: Analytics, Chat-Widgets, Tracking-Pixel, Social Embeds — jedes Script addiert sich
• Große JavaScript-Bundles die nicht code-gesplittet sind — der Browser muss alles parsen bevor er reagieren kann
• Event Listener die aufwändige Berechnungen im Main Thread ausführen
• Hydration bei SSR-Frameworks (React, Next.js) — die Seite SIEHT interaktiv aus, IST es aber noch nicht

1. Chrome DevTools öffnen → Performance Tab → Seite aufnehmen → Auf etwas klicken
2. Die „Long Tasks“ (> 50ms) identifizieren — das sind die Blocker
3. Third-Party Scripts auflisten: Welche sind nötig? Welche können weg oder deferred werden?
4. JavaScript-Bundle analysieren: next/bundle-analyzer zeigt was wie viel wiegt
5. Nicht-kritisches JS mit defer oder dynamic import() laden

Takeaway

Mein Praxis-Tipp: Entferne testweise ALLE Third-Party Scripts und miss INP nochmal. Wenn der Wert jetzt gut ist, weißt du: Die Scripts sind das Problem. Dann fügst du sie einzeln wieder hinzu und siehst welches Script wie viel kostet.

Weiterführende Links: web.dev: Optimize INP

CLS (Cumulative Layout Shift) misst wie stark sich das Layout beim Laden verschiebt. Zielwert: unter 0,1. Ein CLS von 0 ist das Ziel.

Layout Shifts passieren wenn Elemente ihre Größe oder Position ändern NACHDEM der Nutzer die Seite bereits sieht. Das ist frustrierend — besonders wenn du gerade auf einen Button klicken willst und der plötzlich 200px nach unten springt.

| Ursache | Warum es shifted | Fix |
| --- | --- | --- |
| Bilder ohne Dimensionen | Browser weiß nicht wie viel Platz er reservieren soll | width + height Attribute auf alle <img> Tags |
| Fonts die nachladen | Text wird erst in Fallback-Font angezeigt, dann Spring auf Custom Font | font-display: swap + Fonts preloaden |
| Ads / Embeds ohne Platzhalter | Element wird eingefügt und schiebt alles nach unten | Feste Höhe/Breite für Ad-Container reservieren |
| Dynamisch eingefügter Content | Banner, Cookie-Consent, Popups schieben Content | Content von oben einfügen vermeiden, oder min-height setzen |
| CSS die spät lädt | Styles kommen nach dem HTML → Layout ändert sich | Critical CSS inline im <head> |

Takeaway

Der einfachste CLS-Fix der existiert: width und height Attribute auf jedes Bild. Das sagt dem Browser „Reserviere diesen Platz“ bevor das Bild geladen ist. 2 Attribute, 0 Layout Shift.

Diese Maßnahmen brauchen keinen Entwickler und haben sofortigen Impact:

1. Bilder komprimieren: Lade deine 10 größten Bilder auf squoosh.app, exportiere als WebP, lade sie wieder hoch. LCP-Impact: Massiv.
2. Lazy Loading: Füge loading="lazy" zu allen Bildern hinzu die NICHT im sichtbaren Bereich sind (above-the-fold Bilder NICHT lazy laden).
3. Bild-Dimensionen: Füge width und height zu jedem <img> Tag hinzu. CLS-Impact: Sofort.
4. Font-Display: Setze font-display: swap in deiner CSS. Verhindert unsichtbaren Text während Fonts laden.
5. Unnötige Plugins entfernen: WordPress? Deaktiviere Plugins die du nicht brauchst. Jedes Plugin = mehr JS + CSS.

Manche Optimierungen sind nicht mit einem Plugin oder einem Klick erledigt. Hier brauchst du jemanden der den Code anfasst:

• Server-Side Rendering (SSR) oder Static Site Generation (SSG) einrichten — statt Client-Side Rendering
• JavaScript Code-Splitting: Nur das JS laden das auf der aktuellen Seite gebraucht wird
• Critical CSS extrahieren und inline im <head> platzieren — der Rest async laden
• CDN einrichten (Cloudflare, Vercel Edge, AWS CloudFront) für globale Auslieferung
• Hosting wechseln wenn TTFB konsistent über 800ms liegt
• Third-Party Scripts in Web Worker auslagern (Partytown) oder per Consent-Manager lazy laden
• Bildformat-Pipeline: Automatische Konvertierung zu WebP/AVIF mit srcset für verschiedene Geräte

Weiterführende Links: Webentwicklung: Performance-optimierte Websites · Technische SEO-Umsetzung

WordPress ist die häufigste Plattform mit CWV-Problemen — weil jedes Theme und jedes Plugin unkontrolliert CSS und JavaScript lädt. Hier sind die WordPress-spezifischen Fixes:

1. Caching-Plugin installieren: WP Rocket, LiteSpeed Cache oder W3 Total Cache. Sofortiger LCP-Boost.
2. Bildoptimierungs-Plugin: ShortPixel oder Imagify — komprimiert automatisch und konvertiert zu WebP.
3. Unused CSS entfernen: PurifyCSS oder das Feature in WP Rocket — entfernt CSS das auf der Seite nicht gebraucht wird.
4. Plugin-Audit: Deaktiviere alle Plugins → Miss CWV → Aktiviere eins nach dem anderen → Finde die Übeltäter.
5. Theme wechseln (wenn nötig): Manche Themes sind so aufgebläht dass keine Optimierung hilft. GeneratePress, Kadence oder ein Custom Theme sind deutlich schneller.

Takeaway

WordPress mit 30 Plugins und einem Premium-Theme das 2MB JavaScript lädt — da hilft kein Caching-Plugin der Welt. Manchmal ist „weniger Plugins“ die einzige echte Lösung.

Was bringen die Optimierungen konkret? Hier sind realistische Vorher/Nachher-Werte aus der Praxis:

| Maßnahme | LCP vorher | LCP nachher | Aufwand |
| --- | --- | --- | --- |
| Bilder komprimieren + WebP | 4,2s | 1,8s | 30 Min |
| Lazy Loading einrichten | 3,5s | 2,1s | 10 Min |
| CDN aktivieren | 2,8s | 1,4s | 1 Stunde |
| Critical CSS + JS defer | 3,1s | 1,6s | Halber Tag |
| Hosting-Wechsel (Shared → Managed) | 4,5s | 1,9s | 1–2 Stunden |
| Komplett-Optimierung (alles zusammen) | 5,0s+ | < 1,5s | 1–2 Tage |

Weiterführende Links: Google Ranking verbessern — alle Faktoren

80% aller CWV-Probleme lassen sich mit 3 Maßnahmen lösen: Bilder komprimieren, Lazy Loading einrichten und Bild-Dimensionen setzen. Das dauert 30 Minuten und braucht keinen Entwickler.

Für die restlichen 20% — Server-Optimierung, JS Code-Splitting, Critical CSS — brauchst du jemanden der den Code versteht. Das ist kein DIY-Projekt.

Und vergiss nicht: Core Web Vitals sind kein einmaliges Projekt. Jedes neue Plugin, jedes neue Bild, jeder neue Embed kann die Werte verschlechtern. Miss regelmäßig. Am besten monatlich über die Search Console.

Weiterführende Links: Performance-Audit anfragen · Kostenloses Erstgespräch · Google Ranking verbessern: Alle Faktoren · SEO für Online-Shops: Performance-Impact · web.dev: Core Web Vitals · Google: Page Experience Update