Kaum ein SEO-Thema erzeugt so viele Missverständnisse wie die Core Web Vitals. Ein Laborscore von 95 gilt als Erfolg, obwohl Google ihn gar nicht bewertet. Ein roter Wert in der Search Console wird als Rankingverlust gelesen, obwohl Google ausdrücklich sagt, dass Relevanz vorgeht. Dieser Artikel sortiert die Fakten nach den Quellen, die sie festlegen: web.dev und Google Search Central.
Die drei Metriken und ihre Schwellenwerte
Die Core Web Vitals messen drei Aspekte der Nutzererfahrung: Laden, Reaktionsfähigkeit und visuelle Stabilität. Die Schwellenwerte gelten für Mobil und Desktop gleich und werden am 75. Perzentil der Seitenaufrufe gemessen, getrennt nach Gerätetyp. Eine Seite besteht, wenn sie bei allen drei Metriken im Bereich „gut“ liegt.
| Metrik | Was sie misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP Largest Contentful Paint | Ladezeit bis zum größten sichtbaren Bild- oder Textelement | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s |
| INP Interaction to Next Paint | Reaktionszeit auf Klicks, Tippen und Tastatur, über den ganzen Besuch | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS Cumulative Layout Shift | Unerwartete Layout-Verschiebungen, größtes Bündel im Besuch | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Quellen: web.dev, Web Vitals · INP · CLS · Herleitung der Schwellenwerte.
Zwei Details werden oft übersehen. INP hat First Input Delay (FID) abgelöst und misst nicht nur die erste, sondern alle Interaktionen eines Besuchs, vom Klick bis zum nächsten gezeichneten Bild. CLS summiert nicht alle Verschiebungen eines Besuchs, sondern nimmt das größte Bündel: Verschiebungen mit weniger als einer Sekunde Abstand, höchstens fünf Sekunden lang.
Felddaten und Labordaten: was Google bewertet
Felddaten stammen von echten Besuchen. Die wichtigste Quelle ist der Chrome UX Report (CrUX): Chrome-Nutzer, die Nutzungsstatistiken freigegeben haben, über ein rollierendes Fenster von 28 Tagen. Aus diesen Daten speisen sich der Core-Web-Vitals-Bericht der Search Console und der obere Teil von PageSpeed Insights.
Labordaten entstehen in einer kontrollierten Umgebung, meist mit Lighthouse: ein Gerät, ein Netz, ein Seitenaufruf. Sie sind reproduzierbar und zeigen Ursachen, bilden aber nicht ab, was deine Besucher erleben. INP lässt sich im Labor nur eingeschränkt messen, weil ein Labortest meist nur lädt und nicht klickt; Total Blocking Time (TBT) dient dann als Näherung, ist aber kein Ersatz.
Die Unterschiede zwischen beiden Welten erklärt web.dev ausführlich in „Why lab and field data can be different“. Faustregel: Wenn beide nicht übereinstimmen, gilt für die Bewertung das Feld, für die Fehlersuche das Labor.
Rankingwirkung: was Google sagt
Google formuliert hier präzise. In der Dokumentation zur Nutzererfahrung (Page Experience) steht, dass die Core Web Vitals von den Rankingsystemen genutzt werden und gute Werte empfohlen sind. Im selben Text steht aber auch: Gute Ergebnisse in der Search Console oder in Drittanbieter-Tools garantieren keine Top-Platzierung, und einen perfekten Score nur aus SEO-Gründen anzustreben, ist womöglich nicht die beste Verwendung deiner Zeit. Andere Aspekte der Nutzererfahrung helfen laut Google nicht direkt beim Ranking.
Merksatz: Von „schlecht“ auf „gut“ lohnt sich fast immer, für Nutzer und für die Suche. Von „gut“ auf einen perfekten Laborscore lohnt sich selten. Relevanz und Inhalt entscheiden zuerst.
Praxisbeispiel: CLS durch Web-Fonts von 0,46 auf 0,016
Am 4. Oktober 2026 meldeten echte Besucher auf unserer Seite „Website erstellen lassen“ CLS-Werte von 0,47 und 0,63. Nachgestellt mit gedrosseltem Netz und Sprung zum Preisbereich: Die Textschrift Inter (344 KB) kam rund 3,7 Sekunden später an. Bis dahin stand der Text in einer Ersatzschrift mit anderen Maßen. Beim Wechsel brach der Text neu um, und der Preisbereich verrutschte. Labormessung am Desktop: CLS 0,46.
web.dev beschreibt genau diesen Fall: Auch unsichtbar gesetzter Text wird mit der Ersatzschrift angeordnet, deshalb verschiebt der Wechsel zur Web-Font das Layout. Als Gegenmittel nennt web.dev, die Ersatzschrift mit size-adjust, ascent-override, descent-override und line-gap-override an die Web-Font anzugleichen und kritische Schriften früh zu laden. Unser Fix bestand aus zwei Teilen:
- Kleinere Schriftdatei: eine Teilmenge von Inter nur mit lateinischen Zeichen, Satzzeichen und den genutzten Symbolen, 111 statt 344 KB. Sie kommt bei langsamem Netz deutlich früher an.
- Ersatzschrift mit angeglichenen Maßen: Arial, per
@font-faceauf Höhe und Laufweite von Inter gebracht. Bis Inter geladen ist, steht der Text schon fast genauso breit und hoch.
/* Ersatzschrift mit angeglichenen Maßen: Arial wird auf Inter-Größe gebracht */ @font-face { font-family: 'Inter Fallback'; src: local('Arial'), local('ArialMT'); ascent-override: 90.64%; descent-override: 22.57%; line-gap-override: 0%; size-adjust: 106.88%; } body { font-family: 'Inter', 'Inter Fallback', sans-serif; }
Ergebnis in derselben Labormessung: CLS 0,016 statt 0,46, ohne Änderung am Design. Ehrlicher Nachsatz: In den Felddaten ist der Fix noch nicht belegt, weil seitdem zu wenige Chrome-Besuche auf diese Seite kamen; Safari und Firefox melden keinen CLS-Wert. Ob die Besucher seltener springen, zeigt sich erst über die nächsten Wochen.
Typische Ursachen und Hebel je Metrik
Das LCP-Element früh finden und laden
- LCP in vier Teile zerlegen: Time to First Byte, Ladeverzögerung, Ladedauer, Renderverzögerung. Erst messen, welcher Teil groß ist.
- Das LCP-Bild im HTML auffindbar machen (kein Hintergrundbild aus CSS, kein Nachladen per Skript) und mit fetchpriority="high" priorisieren.
- Render-blockierendes CSS und JavaScript reduzieren, Server-Antwortzeit (TTFB) senken.
Quelle: web.dev: LCP optimieren
Den Hauptthread frei halten
- Lange Aufgaben (Long Tasks) aufteilen und dem Browser zwischendurch Zeit zum Zeichnen geben.
- Eingabeverzögerung durch Skripte beim Laden senken, vor allem Drittanbieter-Skripte prüfen.
- DOM-Größe begrenzen; große Bereiche außerhalb des Bildschirms mit content-visibility später rendern.
Quelle: web.dev: INP optimieren
Platz reservieren, bevor Inhalt kommt
- Bildern und Videos width und height mitgeben oder per aspect-ratio Platz reservieren.
- Werbung, Einbettungen, iframes und nachgeladene Hinweise (Cookie-Banner, Statusmeldungen) mit fester Fläche einplanen.
- Web-Fonts so laden, dass der Wechsel von der Ersatzschrift nichts verschiebt (Beispiel unten).
Quelle: web.dev: CLS optimieren
Messen: welche Quelle wofür
- Search Console, Bericht „Core Web Vitals“: Felddaten je URL-Gruppe, der Blick, den Google auf deine Website hat. Ideal, um betroffene Seitentypen zu finden.
- PageSpeed Insights: oben Felddaten aus CrUX für URL und Ursprung, unten Labordiagnose mit Lighthouse. Gut für eine einzelne Seite.
- Eigene Messung echter Besuche (Real User Monitoring): Werte je Seitenaufruf, auch für Seiten ohne CrUX-Daten und für einzelne Wege wie den Sprung per Anker. So haben wir das Schrift-Problem gefunden.
- Unser Core Web Vitals Check: Felddaten aus dem Chrome UX Report für Mobil und Desktop, URL und Domain nebeneinander, mit Verlauf der letzten Wochen und Labordiagnose.