Core Web Vitals 2026: die aktuellen Kennzahlen
Die aktuellen Core Web Vitals sind LCP, INP und CLS. LCP misst Ladeleistung, INP die Reaktionsfähigkeit von Interaktionen und CLS die visuelle Stabilität. Google beschreibt sie als zentrale, nutzerorientierte Aspekte realer Seitenerfahrung. [1][3]
FID gehört nicht mehr zum aktuellen Set. INP ersetzte FID im März 2024, später wurde FID aus CrUX entfernt. 2026 sollten Teams LCP, INP und CLS überwachen. [7][14]
Grenzwerte und 75. Perzentil
| Metrik | Gut | Verbesserungsbedarf | Schlecht | Misst |
|---|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5 s - 4.0 s | > 4.0 s | Laden des Hauptinhalts |
| INP | ≤ 200 ms | 200 ms - 500 ms | > 500 ms | Reaktionsfähigkeit |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 | Visuelle Stabilität |
Gut sind LCP ≤ 2,5 s, INP ≤ 200 ms und CLS ≤ 0,1. Verbesserungsbedarf liegt bei 2,5 bis 4,0 s, 200 bis 500 ms und 0,1 bis 0,25. Darüber gelten die Werte als schlecht. [3][4]
Google bewertet nicht den Durchschnitt, sondern das 75. Perzentil. Mindestens 75% der Erfahrungen sollten den Zielwert erreichen oder besser sein. Mobile und Desktop werden getrennt betrachtet. [3][4]
Die Gesamtbewertung besteht nur, wenn alle drei Kennzahlen am 75. Perzentil gut sind. [3]
Core Web Vitals und SEO
Google bestätigt, dass Core Web Vitals in Ranking-Systemen als Teil der Seitenerfahrung verwendet werden. Gute Werte garantieren aber keine Spitzenposition, da Relevanz und Inhaltsqualität weiterhin entscheidend sind. [1][2]
Die Optimierung verbessert also reale Nutzererfahrung und beseitigt zugleich eine technische Schwäche, ersetzt aber keine gute Suchintention oder Inhalte.
LCP: was genau gemessen wird
Largest Contentful Paint misst die Zeit vom Navigationsbeginn bis das größte qualifizierende Bild, Textsegment oder andere Inhaltselement im Viewport gerendert ist. Felddaten können Redirects, Verbindungsaufbau und TTFB mit einschließen. [5]
LCP ist deshalb nicht einfach die Downloadzeit des größten Bildes. Die Verzögerung kann bereits vor dem Ressourcenabruf entstehen. [5][6]
LCP in der Praxis: vier Teilzeiten analysieren
web.dev teilt LCP in TTFB, Resource Load Delay, Resource Load Duration und Element Render Delay auf. Zusammen ergeben sie den vollständigen LCP. [6]
Wird die LCP-Ressource spät entdeckt, kann reine Kompression wirkungslos bleiben. Sie sollte möglichst im initialen HTML erkennbar sein, und ein LCP-Bild sollte nicht lazy geladen werden. Bei Bedarf helfen Priorisierung oder Preload. [6]
Die Diagnose-Reihenfolge lautet: TTFB prüfen, Zeitpunkt der Ressourcenerkennung bestimmen, Transferdauer messen und anschließend Render-Verzögerungen untersuchen. [6]
- TTFB durch Cache, CDN, weniger Redirects und schnelleres Backend reduzieren.
- LCP-Ressource möglichst im initialen HTML verfügbar machen.
- Kein `loading="lazy"` für das LCP-Bild.
- Bei später Erkennung passende Priorisierung oder Preload nutzen.
- Bildgröße und Format nur optimieren, wenn der Transfer tatsächlich bremst.
- Blockierendes JavaScript oder CSS vor dem finalen Render reduzieren.
INP: Reaktionsfähigkeit über die gesamte Sitzung
Interaction to Next Paint beobachtet Klicks, Taps und Tastatureingaben während des gesamten Besuchs. Meist wird die langsamste Interaktion berichtet. Bei vielen Interaktionen wird eine schlechteste Interaktion pro 50 Interaktionen ignoriert, um Ausreißer zu begrenzen. [7]
INP unterscheidet sich von FID: Es umfasst Eingabeverzögerung, Verarbeitung und die Zeit bis zum nächsten Paint. [7][8]
Ohne Klick, Tap oder Tastatureingabe kann eine Sitzung keinen INP-Wert haben. Scrollen und Hover zählen nicht. [7]
INP in der Praxis: drei Quellen der Verzögerung
Die Interaktionslatenz besteht aus Input Delay, Processing Duration und Presentation Delay. Schlechter INP kann daher durch einen blockierten Main Thread, langsame Handler oder teures Layout und Rendering entstehen. [8]
Hilfreich sind kürzere Long Tasks, aufgeteilte Arbeit, weniger schweres JavaScript, geringere Layout-Kosten, geeignete Web Workers und schnelles visuelles Feedback. [8]
Starte möglichst mit RUM-Daten, die eine konkrete langsame Interaktion zeigen, und reproduziere sie danach in DevTools. Lighthouse allein bildet echten INP nicht vollständig ab. [8][11][12]
CLS: Layout-Stabilität über die gesamte Lebensdauer
Cumulative Layout Shift misst unerwartete Bewegungen sichtbarer Elemente. Verwendet wird das größte Sitzungsfenster, in dem aufeinanderfolgende Verschiebungen weniger als eine Sekunde auseinanderliegen und das gesamte Fenster maximal fünf Sekunden dauert. [9]
CLS ist dimensionslos und kombiniert Auswirkung und Verschiebungsdistanz. Bestimmte direkt nutzerinitiierte Änderungen können ausgeschlossen werden. [9]
Probleme treten oft erst nach dem Laden auf, etwa durch Werbung, Banner, Widgets oder Font-Wechsel. Ein einzelner Labortest kann das übersehen. [10][11]
CLS in der Praxis: typische Ursachen
web.dev nennt Bilder ohne Abmessungen, Werbung, Embeds und iframes ohne reservierten Platz, dynamisch eingefügten Inhalt und Webfonts als typische Ursachen. [10]
Reserviere Platz, bevor Inhalte erscheinen. Bilder brauchen `width` und `height` oder ein stabiles `aspect-ratio`, Werbeslots und Embeds vorhersehbare Dimensionen. Neue Inhalte sollten nicht oberhalb bereits gelesener Inhalte eingefügt werden. [10]
Bei Fonts sollten Unterschiede zwischen Fallback und finaler Schrift reduziert und real getestet werden. `font-display` allein löst nicht jeden CLS-Fall. [10]
Felddaten gegen Labordaten
Core Web Vitals sind primär Feldmetriken. CrUX und eigenes RUM zeigen reale Nutzer über unterschiedliche Geräte und Netze. Lighthouse dient kontrollierter Diagnose im Labor. [11][12]
Lighthouse misst keinen vollständigen realen INP und verwendet unter anderem TBT als Hilfsmetrik. Labor-CLS kann niedriger sein, wenn Verschiebungen erst nach Interaktionen auftreten. [11][12]
Felddaten beantworten, ob ein reales Problem besteht. Labordaten helfen, die Ursache reproduzierbar zu beheben.
Welche Werkzeuge wann sinnvoll sind
| Werkzeug | Datentyp | Beste Nutzung |
|---|---|---|
| PageSpeed Insights | CrUX + Lighthouse | Schneller URL- und Origin-Check |
| Search Console | CrUX, URL-Gruppen | SEO-relevante Problemgruppen finden |
| Chrome DevTools | Labor + CrUX-Kontext | LCP, INP und CLS detailliert debuggen |
| Lighthouse | Labor | Automatische Audits und CI-Regressionschecks |
| RUM / web-vitals | Eigene Nutzerdaten | Präzises Monitoring nach Releases |
PageSpeed Insights kombiniert CrUX mit Lighthouse. Search Console gruppiert ähnliche URLs. Chrome DevTools bietet Live Metrics und detaillierte Traces. [12][13]
CrUX API und PageSpeed Insights basieren auf einem rollierenden Zeitraum von ungefähr 28 Tagen. Eine heutige Änderung schlägt daher nicht sofort im öffentlichen p75 durch. Eigenes RUM reagiert deutlich schneller. [12][13]
Für Produktteams ist RUM ideal fürs Monitoring, Search Console für SEO-Gruppen, PSI für schnelle öffentliche Checks und DevTools für Ursachenanalyse.
CrUX 2026: der aktuelle Stand des Webs
| Metrik | Origins mit gutem Wert, Juli 2026 |
|---|---|
| LCP | 68,3% |
| INP | 85,7% |
| CLS | 81,6% |
| Alle Core Web Vitals | 55,7% |
Der letzte vor dem 4. September 2026 veröffentlichte monatliche CrUX-Datensatz betrifft Juli 2026 und wurde am 11. August veröffentlicht. Er enthält 18.059.068 Origins. 68,3% hatten guten LCP, 81,6% guten CLS, 85,7% guten INP und 55,7% bestanden alle Core Web Vitals. [14]
Das sind aggregierte Webdaten, keine Zielwerte für eine einzelne Website. CrUX enthält nur ausreichend populäre und öffentlich auffindbare Seiten und Origins. [13][14]
Fehlende CrUX-Daten bedeuten daher nicht automatisch gute oder schlechte Performance.
SPAs und Soft Navigations: wichtige Änderung 2026
Core Web Vitals waren historisch stark auf vollständige Dokumentnavigation ausgerichtet. Chrome 151 brachte 2026 neue APIs zur Messung von Soft Navigations, die Dokumentation wurde am 2. September 2026 aktualisiert. [15]
Chrome DevTools 152 vom 25. August 2026 zeigt Core Web Vitals für Soft Navigations standardmäßig in Live Metrics und nutzt dafür `web-vitals` 6.0.0. [16]
Das ist relevant für React, Angular, Vue und andere SPAs. Man sollte aber nicht automatisch annehmen, dass alle öffentlichen CrUX-Berichte Soft Navigations bereits identisch auswerten.
Produktionsmonitoring mit Kontext
Ein öffentlicher p75 zeigt oft nur, dass ein Problem existiert. Eigenes RUM kann LCP-Element und Teilzeiten, die INP-Interaktion, Route, Gerät und App-Version mitsenden. web.dev empfiehlt RUM als Ergänzung zu CrUX. [3][8][12]
Versioniere Deployments und vergleiche Verteilungen vor und nach Änderungen. Durchschnittswerte können Probleme langsamer Geräte verstecken.
CI verhindert offensichtliche Laborregressionen, ersetzt aber kein Produktionsmonitoring. [11][12]
Praktischer Verbesserungsplan
Bestimme zuerst, welche Kennzahl am p75 scheitert und auf welchen Seitentypen. Grenze das Problem mit RUM oder CrUX ein, reproduziere es in DevTools, behebe die konkrete Ursache und überwache das Ergebnis nach dem Deployment. [12]
Für LCP suche die dominante Teilzeit, für INP die echte langsame Interaktion und für CLS die konkreten Verschiebungen.
Prüfe danach Labor- und Felddaten. Öffentliche CrUX-Daten reagieren verzögert, daher ist eigenes RUM für schnelle Bestätigung besonders wertvoll.
- Problem zuerst in Felddaten identifizieren.
- Mobile und Desktop getrennt betrachten.
- Bei LCP TTFB, Ressourcenerkennung, Transfer und Render-Verzögerung prüfen.
- Bei INP die konkrete Interaktion und ihre drei Latenzphasen prüfen.
- Bei CLS die gesamte Sitzung auf Verschiebungen beobachten.
- Eine messbare Änderung ausrollen und vorher/nachher vergleichen.
- RUM und Regression-Alerts dauerhaft betreiben.
