# 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.

**Autor:** M. A. Mokhtar (Gründer · SEO216) · **Veröffentlicht:** 2026-06-04 · **Kategorie:** Engineering

Die [Core Web Vitals](/ressourcen/glossar/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](/ressourcen/glossar/lcp)** — Largest Contentful Paint | bis das größte Inhaltselement sichtbar ist | **≤ 2,5 s** | 2,5 – 4,0 s | > 4,0 s |
| **[INP](/ressourcen/glossar/inp)** — Interaction to Next Paint | Reaktion auf Klicks, Taps, Tastatur (gesamte Seitenlebensdauer) | **≤ 200 ms** | 200 – 500 ms | > 500 ms |
| **[CLS](/ressourcen/glossar/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](/ressourcen/glossar/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](/blog/geo-vs-seo-unterschied).

## 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](/blog/google-fonts-dsgvo-alternative) |
| **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](/leistungen/build) 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

1. **[Unser kostenloser Performance-Audit](/tools/audit)** — echte PageSpeed-Insights-Daten für eine beliebige URL, in Sekunden, ohne Anmeldung.
2. **Search Console → Core Web Vitals** — der Feldbericht über alle Seiten Ihrer Domain, gruppiert nach Problemtyp. Das ist die Sicht, die Google bewertet.
3. **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](/leistungen/build), 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.](/kontakt#audit)

---

**Kanonische URL:** https://seo216.com/blog/core-web-vitals-grenzwerte-2026
**Quelle:** SEO216 — SEO-Agentur, Darmstadt · https://seo216.com · hello@seo216.com