Seit März 2024 hat Interaction to Next Paint (INP) die bisherige Metrik FID abgelöst. Die Core Web Vitals bestehen 2026 also aus drei Kennzahlen: LCP, INP, CLS. Alle drei sind direkter Ranking-Faktor bei Google.
Laut Web Almanac 2025 (Chrome User Experience Report) bestehen nur 48 % aller mobilen Websites alle drei Core Web Vitals gleichzeitig, auf Desktop 56 %. Für viele Mittelständler heißt das: mindestens eine Metrik liegt noch im roten oder gelben Bereich. Hier erklären wir die Werte und zeigen, wie du sie systematisch in den grünen Bereich bringst.
Inhaltsverzeichnis
1. LCP – Largest Contentful Paint
Was wird gemessen?
Zeit vom Aufruf der Seite bis das größte sichtbare Element (meist Hero-Bild oder Headline) geladen ist.
Zielwerte (Google)
- Gut: ≤ 2,5 Sekunden
- Verbesserungsbedarf: > 2,5 bis 4 Sekunden
- Schlecht: > 4 Sekunden
Häufige Ursachen für schlechten LCP
- Riesige, unoptimierte Hero-Bilder (JPG statt WebP/AVIF)
- Web Fonts blockieren den Render
- Server-Antwortzeit zu hoch (TTFB > 800ms)
- JavaScript-Bundle blockiert kritischen Pfad
Wie du LCP optimierst
- Hero-Bilder mit dem priority-Attribut markieren
- Bildformat: WebP oder AVIF. Reduziert Größe um 30–60 % bei gleicher Qualität.
- Bilder mit srcSet für verschiedene Bildschirmgrößen
- Server-seitiges Rendering (SSR) statt SPA-Rendering
- Edge-Caching (Vercel, Cloudflare)
- Font-Loading mit font-display: swap und Preload
2. INP – Interaction to Next Paint
Was wird gemessen?
Zeit zwischen einer Nutzerinteraktion (Klick, Tap, Keystroke) und der sichtbaren Reaktion der UI.
Zielwerte
- Gut: ≤ 200 ms
- Verbesserungsbedarf: > 200 bis 500 ms
- Schlecht: > 500 ms
Wichtig zu wissen
INP misst nicht nur den ersten Klick (wie FID früher), sondern alle Interaktionen auf der Seite. Schlechte INP-Werte fallen oft bei:
- Komplexen Forms mit Validierungs-JavaScript
- SPA-Routern, die viele Komponenten neu rendern
- Third-Party-Scripts (Tracking, Chat, Cookie-Banner)
Wie du INP optimierst
- JavaScript-Bundles reduzieren (Code-Splitting, Tree-Shaking)
- Third-Party-Scripts mit defer oder via Web Worker laden
- React 18+: useTransition und useDeferredValue für teure Updates
- Event-Handler debouncing/throttling
- Lange JavaScript-Tasks (> 50ms) in kleinere zerlegen
- Bei Bedarf: Hydration Boundaries (Astro, Next.js Server Components)
3. CLS – Cumulative Layout Shift
Was wird gemessen?
Wie stark sich das Layout während des Ladens „verschiebt". Ein klassisches Beispiel: du willst auf einen Button klicken, plötzlich verschiebt sich alles, weil ein Werbebanner geladen wurde, und du klickst auf etwas anderes.
Zielwerte
- Gut: ≤ 0,1
- Verbesserungsbedarf: > 0,1 bis 0,25
- Schlecht: > 0,25
Häufige Ursachen für schlechten CLS
- Bilder ohne explizite width/height-Attribute
- Lazy-geladene Werbebanner ohne reservierten Platz
- Web Fonts, die mit dem Standard-Font unterschiedliche Höhen haben
- Dynamisch eingefügter Content über bestehendem (z. B. Cookie-Banner)
Wie du CLS optimierst
- Alle Bilder mit width und height versehen (oder per CSS aspect-ratio)
- Platzhalter reservieren für lazy-loaded Content
- size-adjust für Font-Loading
- Cookie-Banner oben fixieren statt einklappen
4. Lab vs. Field Data
Wichtig zu verstehen: Google nutzt für das Ranking Field Data (echte Nutzer aus dem Chrome User Experience Report, CrUX), nicht Lab Data (deine Lighthouse-Tests).
Das bedeutet: ein Lighthouse-Score von 95 ist schön, sagt aber wenig über das echte Ranking. Wichtiger ist die Search Console → Core Web Vitals → Bericht, der echte Nutzerdaten zeigt.
5. Die 10 effektivsten Optimierungen (in Reihenfolge)
- Bilder auf WebP/AVIF konvertieren
- Hero-Bild mit priority markieren
- Font-Loading optimieren (preload + font-display: swap)
- JavaScript-Bundle kleiner machen (Bundle Analyzer)
- Third-Party-Scripts mit defer oder erst nach User-Interaction laden
- Server-seitiges Rendering nutzen (Next.js, Astro, Nuxt)
- Edge-Caching aktivieren
- Width/Height auf alle Bilder setzen
- Cookie-Banner so designen, dass kein Layout-Shift entsteht
- HTTP/2 oder HTTP/3 nutzen
6. Tools zur Messung
- Google Search Console: Core Web Vitals Report (Field Data, am wichtigsten)
- PageSpeed Insights: Lab + Field Data, gute Übersicht
- Chrome DevTools → Lighthouse: Lab-Tests für lokale Optimierung
- WebPageTest.org: detaillierte Wasserfall-Analysen
- Vercel Speed Insights: RUM für Next.js-Sites
7. Fazit & Empfehlung
Core Web Vitals sind 2026 keine optionale Performance-Spielerei – sie entscheiden über Ranking und Conversion. Eine 100ms schnellere Seite kann 1–2 % Conversion-Steigerung bringen.
Wenn deine Website auf WordPress läuft und du Core Web Vitals optimieren willst, kommst du oft an einen Punkt, wo die Architektur die Grenze setzt. Mit Next.js + Strapi sind grüne Core Web Vitals der Standard, nicht die Ausnahme.
Wir bauen Websites, die in allen drei Metriken grün sind – ohne Workarounds. Schau dir an, wie wir arbeiten.