Core Web Vitals 2026:
INP, LCP, CLS verstehen und optimieren
Zusammenfassung
Core Web Vitals 2026 sind Googles offizielle Performance-Metriken. INP ersetzt FID seit März 2024, LCP misst Ladezeit, CLS Layout-Stabilität. 47% deutscher Websites scheitern an den Schwellwerten - dieser Guide zeigt Optimierung mit Code-Beispielen und Checkliste.
- 47% deutscher Websites scheitern an Core Web Vitals (2026)
- INP (Interaction to Next Paint) ersetzt FID - strenger, misst alle Interaktionen
- Zielwerte: INP ≤200ms, LCP ≤2.5s, CLS ≤0.1
- Field Data (CrUX) zählt für Rankings, nicht Lab Data
- 28-30 Tage bis Verbesserungen in Search Console sichtbar sind
47% aller deutschen Websites scheitern an Googles Core Web Vitals. Seit INP (Interaction to Next Paint) im März 2024 FID ersetzt hat, sind die Anforderungen noch strenger. Dieser umfassende Guide zeigt Ihnen, wie Sie alle drei Core Web Vitals verstehen, messen und optimieren - mit praktischen Code-Beispielen und einer vollständigen Checkliste.
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
LCP
Largest Contentful Paint - misst die Ladezeit des größten sichtbaren Elements
CLS
Cumulative Layout Shift - misst unerwartete Layout-Verschiebungen
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 grosste 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"
/>
<!-- Fur 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 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
}
} Vollstandiges Code-Beispiel: Optimierte Hero Section
Hier ist ein vollständig optimiertes Hero-Section Beispiel, das alle Core Web Vitals Best Practices 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> Core Web Vitals Checkliste 2026
INP Optimierung
LCP Optimierung
CLS Optimierung
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.
Fazit: Core Web Vitals als Wettbewerbsvorteil
Core Web Vitals sind mehr als nur eine SEO-Metrik - sie sind ein Indikator für Nutzerzufriedenheit. Mit den richtigen Optimierungen können Sie:
- Bessere Google-Rankings durch technische Exzellenz erreichen
- Absprungraten um 20-30% reduzieren
- Conversion-Rates um 10-25% steigern
- Mobile Nutzer (70%+ des Traffics) besser bedienen
- Sich von 47% der Konkurrenz abheben, die scheitert
Beginnen Sie mit der Messung Ihrer aktuellen Werte, priorisieren Sie die größten Probleme, und arbeiten Sie systematisch durch unsere Checkliste. Mit diesem Guide haben Sie alle Werkzeuge für Top-Performance 2026.
Quellen & Referenzen
Dieser Artikel basiert auf folgenden verifizierten Quellen:
Dokumentation
- 1.
- 2.
- 3. Optimizing Interaction to Next Paint Externe QuelleGoogle • 2024
- 4.
Forschung
- 1. Core Web Vitals Technology Report - HTTP Archive Externe QuelleHTTP Archive • 2026
Core Web Vitals Optimierung gewünscht?
Wir analysieren Ihre Website und optimieren alle Core Web Vitals auf "Gut". Mit Garantie für bessere Werte.