Was Core Web Vitals 2026 eigentlich sind — und warum sie zählen
Google misst Core Web Vitals seit 2020 als Rankingfaktor. Was 2020 noch als "nice to have" galt, ist 2026 Pflicht: Wer im Local Pack und in den organischen Top-10 mitspielen will, kommt um grüne Vitals nicht herum. Google hat in den letzten drei Jahren die Gewichtung schrittweise erhöht, die Metriken verfeinert und im März 2024 INP als Ersatz für FID eingeführt — was viele Sites kalt erwischt hat, weil INP deutlich härter zu bestehen ist.
Dieser Artikel ist der aktuelle Stand im April 2026: welche Metriken gelten, welche Schwellenwerte Google verwendet, welche Hebel wirklich wirken, und wie Lighthouse 12 sich von früheren Versionen unterscheidet.
Die drei aktuellen Vitals
1. LCP (Largest Contentful Paint)
LCP misst den Zeitpunkt, an dem das größte sichtbare Element im Viewport gerendert ist — meistens ein Hero-Bild, ein H1-Text oder ein Video-Poster. Das ist der Moment, in dem der Nutzer das Gefühl hat, die Seite sei "da".
2. INP (Interaction to Next Paint)
INP hat seit März 2024 FID ersetzt und misst die Reaktionsgeschwindigkeit der Seite auf Eingaben — nicht nur die erste Interaktion, sondern alle. Wenn ein Button 400 ms braucht, bis er visuell reagiert, ist der INP schlecht. JavaScript-Frameworks mit teurer Hydration tun sich hier schwer.
3. CLS (Cumulative Layout Shift)
CLS misst, wie stark das Layout während des Ladens springt — wenn ein Bild nachgeladen wird und den Text nach unten schiebt, wenn ein Cookie-Banner plötzlich erscheint, wenn ein Ad-Slot die Textspalte verschiebt. Jeder Shift kostet Punkte.
Die aktuellen Schwellenwerte
| Metrik | Gut | Verbesserung nötig | Schlecht |
|---|---|---|---|
| LCP | unter 2.5s | 2.5–4.0s | über 4.0s |
| INP | unter 200ms | 200–500ms | über 500ms |
| CLS | unter 0.1 | 0.1–0.25 | über 0.25 |
Wichtig: Google bewertet anhand des 75. Perzentils der echten Nutzerdaten (Field Data via CrUX). Das heißt: Wenn 75% deiner realen Nutzer einen LCP unter 2.5s haben, giltst du als "gut". Das ist strenger als Lab-Tests via Lighthouse, die auf einem definierten Testgerät laufen.
Warum INP der neue Stress ist
FID (First Input Delay) war eine sanfte Metrik: Sie maß nur die erste Interaktion, und nur die Zeit bis zum Event-Handler-Start — nicht bis der Nutzer was sah. INP ist härter:
- Misst alle Interaktionen, nicht nur die erste
- Misst Ende-zu-Ende: Klick → Event → JavaScript → Render → Paint
- Nimmt das schlechteste Ergebnis pro Sitzung (oder Perzentil)
- Deckt Long Tasks gnadenlos auf
Alte React-Setups mit clientseitiger Hydration tun sich hier besonders schwer. Wenn deine App 8 MB JavaScript lädt und 2 Sekunden hydriert, wirst du INP-technisch nicht glücklich. Server Components, Astro Islands und Qwik sind die sauberen Antworten.
Praktische Hebel für LCP
- Hero-Image mit priority-Attribut markieren, damit der Browser es prio-lädt
- Schriften mit display: swap und Preload — kein unsichtbarer Text mehr während Schrift lädt
- Above-the-Fold ohne Blocking-CSS — kritisches CSS inline, Rest async
- CDN für alle Assets (Vercel, Cloudflare, Bunny) statt Origin-Server
- Responsive Images mit sauberen srcset und sizes, nicht ein 4k-JPEG für alle Geräte
- WebP oder AVIF statt JPEG — 30–50% kleiner bei gleicher Qualität
- Preconnect zu wichtigen Third-Party-Domains (fonts.gstatic, google-analytics)
- HTTP/3 aktivieren, falls der Host es unterstützt
- Server-Side Rendering oder Static Generation statt Client-Side Rendering
Beispiel in Next.js:
import Image from "next/image";
<Image
src="/hero.jpg"
alt="Hero"
width={1920}
height={1080}
priority
sizes="(max-width: 768px) 100vw, 1920px"
/>;Praktische Hebel für INP
- Lange Tasks aufteilen via scheduler.yield() oder setTimeout
- Hydration nur dort wo nötig (React Server Components, Astro Islands)
- Heavy JavaScript aus dem Critical Path — dynamic imports, Code-Splitting
- useDeferredValue und useTransition in React für teure Updates
- Passive Event Listeners für scroll/touch
- Web Workers für CPU-intensive Arbeit
- Debounce/Throttle bei häufigen Events (resize, scroll, input)
Die größten INP-Killer in meinen Audits: alte Third-Party-Skripte. Facebook Pixel aus 2019, Hotjar in der alten Version, ein vergessener Chatbot. Einmal alles rauswerfen, was nicht aktiv genutzt wird — spart typisch 100–200 ms INP.
Praktische Hebel für CLS
- Bildmaße immer setzen (width + height oder aspect-ratio)
- Schriftarten mit size-adjust definieren, um Fallback-Swap auszugleichen
- Keine dynamischen Banner oberhalb vom Content (Cookie-Banner bitte als Overlay)
- Platzhalter für Ad-Slots in der vollen Größe reservieren
- Skeletons statt leere Container bei async Content
- CSS transform statt top/left für Animationen
Was Lighthouse 12 anders macht
Lighthouse 12 (veröffentlicht Herbst 2025) hat ein paar wichtige Änderungen:
- INP-basierte Performance-Score-Berechnung statt TBT
- Neue LCP-Subparts-Analyse: Time to First Byte, Load Delay, Load Duration, Render Delay — du siehst genau, wo die Zeit verloren geht
- Accessibility-Checks auf WCAG 2.2 Level AA — mehr Kriterien als früher
- Third-Party-Impact-Analyse mit konkreten Empfehlungen pro Third-Party-Skript
Wer mit Lighthouse 8 noch Green Scores hatte, ist mit Lighthouse 12 oft bei Orange — einfach weil die Messung genauer geworden ist.
Was du jetzt tun solltest
- CrUX-Daten checken: search.google.com/search-console/core-web-vitals zeigt dir die echten Field Data deiner Site
- Lighthouse 12 Audit laufen lassen auf den 5 wichtigsten Seiten
- PageSpeed Insights für jede Seite, die im Audit rot ist
- Priorisieren nach Traffic: die Seite, die 40% der Besucher sieht, zuerst optimieren
- Messen, umsetzen, nochmal messen — keine Optimierung ohne Vorher/Nachher-Zahlen
Mein Versprechen
Jede Website, die ich neu baue, kommt mit Lighthouse-Scores 95+ raus. Und das nicht mit Tricks, sondern weil der Stack es ermöglicht: Next.js oder Astro, Server-First, Edge-CDN, optimierte Bilder, minimal Client-Side JavaScript. Wenn deine aktuelle Seite rote Vitals hat und du wissen willst, was realistisch erreichbar ist: 20 Minuten Audit, ehrliche Einschätzung, keine Vertriebsschleife.