Core Web Vitals 2026 — alle Grenzwerte, eine Tabelle.
LCP, INP, CLS: die offiziellen Schwellen, die 75-Prozent-Regel, Labor- vs. Felddaten und die häufigsten Ursachen pro Metrik — das Referenzblatt zum Verlinken, Stand Juni 2026.
Die Core Web Vitals sind drei von Google definierte Messwerte für Nutzererlebnis: LCP (Ladezeit des Hauptinhalts, gut ≤ 2,5 s), INP (Reaktionszeit auf Eingaben, gut ≤ 200 ms) und CLS (visuelle Stabilität, gut ≤ 0,1). Bestanden ist eine Seite, wenn mindestens 75 % der echten Besuche den „guten” Bereich erreichen — gemessen pro Metrik, mobil und Desktop getrennt. Stand Juni 2026 gelten diese Schwellen unverändert.
Dieser Beitrag ist als Referenzblatt gebaut: alle Zahlen, die Messregeln, die häufigsten Ursachen pro Metrik. Zum Verlinken, zum Weitergeben, zum Nachschlagen.
Die Grenzwerte (Stand: Juni 2026)
| Metrik | Misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | bis das größte Inhaltselement sichtbar ist | ≤ 2,5 s | 2,5 – 4,0 s | > 4,0 s |
| INP — Interaction to Next Paint | Reaktion auf Klicks, Taps, Tastatur (gesamte Seitenlebensdauer) | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS — Cumulative Layout Shift | unerwartete Layout-Sprünge (einheitenloser Score) | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Dazu zwei unterstützende Metriken, die keine Core Web Vitals sind, aber die Diagnose tragen: TTFB (Server-Antwortzeit, gute Orientierung ≤ 0,8 s) und FCP (erster sichtbarer Inhalt, gut ≤ 1,8 s). Ein schlechter LCP beginnt fast immer bei einem schlechten TTFB.
Eine Zäsur zur Einordnung älterer Quellen: Seit dem 12. März 2024 ist INP die offizielle dritte Metrik und hat FID (First Input Delay) abgelöst. Texte, die noch FID-Werte empfehlen, sind seitdem veraltet — INP ist deutlich strenger, weil es jede Interaktion über die gesamte Sitzung misst, nicht nur die Verzögerung der ersten.
Die drei Messregeln, an denen Audits scheitern
1. Die 75-Prozent-Regel. Google bewertet das 75. Perzentil der echten Besuche: Eine Seite besteht eine Metrik, wenn mindestens drei Viertel der Aufrufe im grünen Bereich liegen. Der Durchschnitt ist irrelevant — ein guter Mittelwert kann ein Viertel katastrophaler Besuche verstecken.
2. Felddaten schlagen Labordaten. Es zählen die Messwerte echter Chrome-Nutzer (CrUX-Datensatz, sichtbar in PageSpeed Insights und im Core-Web-Vitals-Bericht der Search Console). Lighthouse ist ein Labortest auf einem simulierten Mittelklasse-Mobilgerät — unverzichtbar für die Diagnose, aber nicht das Zeugnis. Deshalb gilt auch: Der eigene Desktop-Browser mit warmem Cache ist als Messinstrument wertlos.
3. Mobil und Desktop werden getrennt bewertet. Bestanden auf dem Desktop heißt nichts für mobil — und mobil ist der Engpass: simulierte Drosselung im Labor, echte Funkverbindungen im Feld, schwächere Geräte. Wer nur eine Zahl prüft, prüft die mobile.
Warum die Schwellen zählen — die ehrliche Einordnung
Core Web Vitals sind Teil von Googles Page-Experience-Bewertung und fließen ins Ranking ein — aber sie sind ein Signal unter vielen, kein Alleinentscheider. Die ehrliche Formel: Gute Werte gewinnen kein Ranking, schlechte Werte verlieren eines. Bei vergleichbarer inhaltlicher Relevanz entscheidet Erfahrung den Tiebreak, und unterhalb der Schwellen kostet jede weitere Sekunde messbar Conversions — der SXO-Teil der Rechnung, der auch ohne Google gilt. Für KI-Crawler mit begrenztem Lesebudget kommt dasselbe Argument noch einmal: schnelle, statische Seiten werden bevorzugt gelesen, der GEO-Teil der Rechnung.
Diagnose: die häufigsten Ursachen pro Metrik
| Metrik | Häufigste Ursachen | Der strukturelle Fix |
|---|---|---|
| LCP | langsamer Server (TTFB), render-blockierendes CSS/JS, unoptimierte Hero-Bilder, externe Schrift-CDNs | vorgerendertes HTML vom Edge, Bilder modern (WebP/AVIF) + dimensioniert, Schriften selbst hosten |
| INP | JavaScript-Hauptthread-Blockaden: Plugin-Schichten, Hydration ganzer Seiten, Third-Party-Tags | weniger JS ausliefern: statisches HTML, Interaktivität nur dort, wo sie gebraucht wird, Tags aussortieren |
| CLS | Bilder ohne Dimensionen, nachladende Banner/Embeds, Schrift-Umbrüche (FOUT ohne swap-Strategie) | feste Dimensionen für alles Nachladende, font-display: swap mit passenden Fallbacks, keine Layout-Injektionen |
Das Muster hinter allen drei Spalten: Die schlechten Werte sind selten ein „Optimierungsproblem” und meist ein Architekturproblem. Ein Stack, der Seiten zur Laufzeit aus einer Datenbank durch Plugin-Schichten rendert, kämpft gegen seine eigene Konstruktion — deshalb erreichen unsere Neubauten und Migrationen auf Astro + Vercel die Schwellen nicht durch Tuning, sondern durch Bauart: vorgerendertes HTML, mobile Ladezeit unter einer Sekunde, Lighthouse-Werte von 95–100 als Normalzustand. Unser internes Budget liegt bewusst unter den offiziellen Schwellen: LCP < 1,0 s, INP < 200 ms, CLS < 0,05.
So messen Sie richtig — in dieser Reihenfolge
- Unser kostenloser Performance-Audit — echte PageSpeed-Insights-Daten für eine beliebige URL, in Sekunden, ohne Anmeldung.
- Search Console → Core Web Vitals — der Feldbericht über alle Seiten Ihrer Domain, gruppiert nach Problemtyp. Das ist die Sicht, die Google bewertet.
- Lighthouse / PageSpeed Insights — die Labordiagnose pro Seite, wenn Sie wissen wollen, warum ein Wert schlecht ist.
Deshalb bauen wir bei SEO216 von vornherein auf Astro und Vercel — statisches HTML von der Edge, sub-Sekunden-LCP ab Tag eins, statt langsame Werte nachträglich zu erkämpfen.
Und wenn die Diagnose steht und die Frage „reparieren oder neu bauen?” im Raum steht: Der vollständige Audit beantwortet sie mit Messwerten, Wettbewerbsvergleich und priorisiertem Plan — innerhalb von 24 Stunden, kostenlos.
