- Die Core Web Vitals sind drei Metriken. LCP misst das Laden, INP die Reaktion auf Eingaben und CLS die visuelle Stabilität. INP hat am 12. März 2024 FID abgelöst.
- Bewertet wird das 75. Perzentil echter Seitenaufrufe, getrennt nach Mobil und Desktop. Ein guter Lighthouse-Score ersetzt diese Felddaten nicht.
- Google nutzt die Core Web Vitals im Ranking. Relevanz geht laut Google aber vor, und gute Werte garantieren keine Top-Position.
Was sind Core Web Vitals?
Core Web Vitals sind die Metriken, mit denen Google und Chrome die Nutzererfahrung beim Laden und Bedienen einer Seite messen. Sie gehören zum Programm Web Vitals auf web.dev. Seit 2024 sind es drei.
| Metrik | Misst | Frage |
|---|---|---|
| LCP, Largest Contentful Paint | Laden | Wann ist das größte sichtbare Element dargestellt, etwa ein Produktbild oder eine Textbox? |
| INP, Interaction to Next Paint | Reaktion | Wie schnell zeigt die Seite eine Reaktion auf Klicks, Taps und Tastendrücke? |
| CLS, Cumulative Layout Shift | Stabilität | Wie stark verschiebt sich der Inhalt unerwartet, während jemand liest? |
INP löste am 12. März 2024 die Metrik First Input Delay ab. FID maß nur die Verzögerung der ersten Eingabe. INP bewertet die Interaktionen während des ganzen Seitenaufrufs. Laut web.dev ändern sich die stabilen Metriken höchstens einmal im Jahr, und Änderungen kündigt Google vorher an.
Grenzwerte
Für jede Metrik gibt es drei Bereiche. Maßgeblich ist das 75. Perzentil aller Seitenaufrufe, getrennt nach Mobil und Desktop. Drei von vier Aufrufen müssen also im guten Bereich liegen.
| Metrik | Gut | Verbesserung nötig | Schlecht |
|---|---|---|---|
| LCP | bis 2,5 s | über 2,5 s bis 4 s | über 4 s |
| INP | bis 200 ms | über 200 ms bis 500 ms | über 500 ms |
| CLS | bis 0,1 | über 0,1 bis 0,25 | über 0,25 |
Eine Seite besteht die Bewertung, wenn alle drei Metriken gut sind. In der Search Console bekommt eine Gruppe von URLs immer den Status ihrer schlechtesten Metrik. Ist CLS schlecht und sind LCP und INP gut, gilt die ganze Gruppe als schlecht.
Wie entstehen die Werte?
- LCP zählt Bilder, Videos, Hintergrundbilder aus CSS und Textblöcke. Das größte dieser Elemente im sichtbaren Bereich bestimmt den Wert.
- INP nimmt die langsamste Interaktion eines Seitenaufrufs. Bei vielen Interaktionen ignoriert die Messung je 50 Interaktionen den höchsten Wert. Scrollen und Hovern zählen nicht.
- CLS fasst Verschiebungen zu Fenstern von höchstens fünf Sekunden zusammen und nimmt das stärkste Fenster. Verschiebungen innerhalb von 500 ms nach einem Klick oder Tastendruck zählen nicht.
Felddaten und Labordaten
Felddaten stammen von echten Besuchern, Labordaten aus einem simulierten Seitenaufruf. Beide sind nützlich und beantworten unterschiedliche Fragen.
| Felddaten | Labordaten | |
|---|---|---|
| Quelle | Chrome User Experience Report (CrUX) oder eigenes Real User Monitoring | Lighthouse, Chrome DevTools |
| Messung | Echte Nutzer, viele Geräte und Netze | Ein Gerät, feste Netzbedingungen |
| Zeitraum | In PageSpeed Insights die letzten 28 Tage | Ein einzelner Aufruf |
| INP | Ja | Nein, Ersatz ist Total Blocking Time |
| Gut für | Bewertung, wie Google sie sieht | Ursachen finden und Fixes testen |
Der Core-Web-Vitals-Bericht der Search Console nutzt CrUX-Felddaten und gruppiert ähnliche URLs. Lighthouse lädt eine einzelne Seite unter festen Bedingungen. Eine Seite kann in Lighthouse 95 Punkte erreichen und in den Felddaten trotzdem durchfallen, etwa weil echte Besucher langsamere Smartphones nutzen oder ein Consent-Banner erst bei ihnen erscheint.
Wer zählt in CrUX?
CrUX erfasst Chrome-Nutzer auf Desktop und Android, die Nutzungsstatistiken teilen und ihren Verlauf synchronisieren. Chrome auf iOS, andere Chromium-Browser wie Edge und WebViews in Apps zählen nicht. Eine Seite erscheint nur mit eigenen Daten, wenn sie öffentlich auffindbar ist, also Status 200 und kein noindex, und genug Besucher hat. Die Schwelle veröffentlicht Google nicht. Für seltener besuchte Seiten gibt es dann nur Werte für die ganze Domain.
Selbst messen
Für eigene Felddaten bindet Google die Bibliothek web-vitals ein. Sie misst die drei Werte im Browser deiner Besucher und gibt sie an deine Analyse weiter.
Typische Ursachen und Fixes
| Metrik | Häufige Ursache | Fix |
|---|---|---|
| LCP | Langsame Serverantwort, HTML wird bei jedem Aufruf neu erzeugt | HTML-Caching, etwa im CDN, schnellere Datenbankabfragen |
| LCP | Hauptbild wird spät entdeckt oder per Lazy Loading geladen | Hauptbild im HTML referenzieren, kein Lazy Loading, fetchpriority="high" |
| LCP | Render-blockierendes CSS und JavaScript | Kritisches CSS inline, Skripte mit defer |
| INP | Lange JavaScript-Aufgaben, oft von Drittanbieter-Skripten | Aufgaben aufteilen, Skripte prüfen und später laden |
| INP | Große DOM-Struktur, aufwendiges Neuzeichnen nach Klicks | DOM verkleinern, nur sichtbare Teile aktualisieren |
| CLS | Bilder und Videos ohne Breite und Höhe | width und height oder aspect-ratio setzen |
| CLS | Anzeigen, Banner und Widgets, die sich nachträglich ausdehnen | Platz vorab reservieren |
| CLS | Webfonts mit anderer Laufweite oder Größe als die Ersatzschrift | Ersatzschrift angleichen, Fonts vorladen |
Beispiel aus der Praxis mit HTML-Caching im Shop
Eine Fallstudie von searchVIU aus dem Jahr 2019 beschreibt das HTML-Caching über Cloudflare in einem Onlineshop. Vorher lieferte Cloudflare nur statische Dateien aus dem Cache, jede HTML-Seite kam frisch vom Server. Die Serverantwort lag im Schnitt bei etwa 1,5 Sekunden. Mit drei Page Rules, heute Cache Rules, wurden Warenkorb und Checkout ausgenommen, Infoseiten einen Tag lang und alle übrigen Seiten 30 Minuten lang gecacht. Eingeloggte Nutzer und Nutzer mit Warenkorb bekamen über ein Cookie immer die frische Seite.
Danach lag die Serverantwort unter einer Sekunde, die durchschnittliche Ladezeit sank von 4,49 auf 3,25 Sekunden, rund 28 Prozent. Gemessen wurde damals mit der Ladezeit aus Google Analytics, LCP gab es noch nicht. Weil die Serverantwort Teil des LCP ist, zeigt das Beispiel trotzdem, wie stark ein schneller Server ins Gewicht fällt. Zur Fallstudie HTML-Caching mit Cloudflare
Einfluss auf Rankings
Google schreibt in der Dokumentation zur Page Experience, dass die Ranking-Systeme die Core Web Vitals nutzen. Im selben Text steht, dass es kein einzelnes Signal gibt und Google immer den relevantesten Inhalt zeigt, auch bei schwacher Page Experience. Eine gute Nutzererfahrung kann den Ausschlag geben, wenn viele hilfreiche Seiten zur Auswahl stehen.
Gute Werte im Core-Web-Vitals-Bericht garantieren laut Google keine Top-Position. Google bewertet überwiegend je Seite. Einige Bewertungen gelten für die ganze Website. Die übrigen Aspekte der Page Experience wie HTTPS, mobile Darstellung oder störende Interstitials helfen laut Google nicht direkt im Ranking, verbessern aber die Nutzererfahrung.
Häufige Fehler
- Auf den Lighthouse-Score optimieren und die Felddaten nicht ansehen.
- Nur die Startseite prüfen. Produkt- und Kategorieseiten haben andere Templates und oft andere Werte.
- Mobil und Desktop zusammen betrachten. Google bewertet beide getrennt.
- Nach einem Fix sofort neue Felddaten erwarten. CrUX und die Validierung in der Search Console laufen über 28 Tage.
- Das Hauptbild per Lazy Loading laden und damit den LCP verschlechtern.
Häufige Fragen
Was sind Core Web Vitals?
Drei Metriken von Google für die Nutzererfahrung. LCP misst das Laden, INP die Reaktion auf Eingaben und CLS die visuelle Stabilität einer Seite.
Sind Core Web Vitals ein Rankingfaktor?
Ja, Google nutzt sie laut eigener Dokumentation im Ranking. Relevanz geht aber vor, und gute Werte allein bringen keine Top-Position.
Was ist ein guter LCP-Wert?
2,5 Sekunden oder weniger, gemessen am 75. Perzentil echter Seitenaufrufe. Über 4 Sekunden gilt als schlecht.
Was ist ein guter CLS-Wert?
0,1 oder weniger. Über 0,25 gilt als schlecht. Häufige Ursachen sind Bilder ohne Maße, nachgeladene Anzeigen und Webfonts.
Warum zeigt die Search Console andere Werte als Lighthouse?
Die Search Console nutzt Felddaten echter Chrome-Nutzer der letzten Wochen, Lighthouse einen einzelnen simulierten Aufruf. Beide messen deshalb verschiedene Dinge.
Wie kann ich die Performance meiner Website messen?
PageSpeed Insights zeigt Feld- und Labordaten für einzelne URLs, der Core-Web-Vitals-Bericht der Search Console Gruppen von URLs. Für eigene Felddaten bindest du die Bibliothek web-vitals ein.
Quellen
Abgerufen am 15.10.2026. Ist eine Angabe veraltet oder fehlt etwas, schreib uns.
- web.dev, Web Vitals: https://web.dev/articles/vitals · Stand 31.10.2024
- web.dev, Largest Contentful Paint: https://web.dev/articles/lcp · Stand 04.09.2025
- web.dev, Interaction to Next Paint: https://web.dev/articles/inp · Stand 02.09.2025
- web.dev, Cumulative Layout Shift: https://web.dev/articles/cls · Stand 12.04.2023
- web.dev Blog, INP wird am 12. März Core Web Vital: https://web.dev/blog/inp-cwv-march-12 · Stand 31.01.2024
- Google Search Central, Page Experience: https://developers.google.com/search/docs/appearance/page-experience · Stand 22.09.2026
- Chrome for Developers, CrUX-Methodik: https://developer.chrome.com/docs/crux/methodology · Stand 20.06.2024
- PageSpeed Insights, Über PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about · Stand 21.10.2024
- Search-Console-Hilfe, Bericht Core Web Vitals: https://support.google.com/webmasters/answer/9205520 · Abruf 15.10.2026
- GoogleChrome, web-vitals: https://github.com/GoogleChrome/web-vitals