Was sind Core Web Vitals?

Was sind Core Web Vitals?

Core Web Vitals (CWV) sind drei feldgemessene Metriken, mit denen Google die echte Nutzererfahrung auf einer Webseite bewertet: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Jede erfasst eine andere Dimension der Nutzererfahrung: wie schnell sich die Seite anfühlt, wie reaktionsfreudig sie auf Eingaben ist und wie stabil das Layout während des Ladens bleibt. Seit dem Page-Experience-Update 2021 sind CWV ein bestätigtes Google-Ranking-Signal — Seiten, die gute Schwellenwerte über alle drei Metriken erreichen, werden gegenüber Seiten bevorzugt, die das nicht tun.

Die Metriken werden von echten Chrome-Nutzern gemessen (dem Chrome User Experience Report, kurz CrUX), nicht von synthetischen Lab-Tools. Deshalb können zwei Seiten mit identischem Lighthouse-Score sehr unterschiedliche CWV-Werte in der Produktion haben. CWV ist der Vertrag zwischen dem, was dein Code tut, und dem, was echte Nutzer auf echten Netzwerken tatsächlich erleben.

Die 3 Core-Web-Vitals-Metriken

Largest Contentful Paint (LCP)

LCP misst, wie lange das größte sichtbare Inhaltselement (meist ein Hero-Bild, ein großer Textblock oder ein Video-Poster) braucht, um im Viewport gerendert zu werden. Es erfasst die wahrgenommene Ladegeschwindigkeit. Gut: unter 2,5 Sekunden. Verbesserung nötig: 2,5–4,0 s. Schlecht: über 4,0 s. Google nutzt das 75. Perzentil über 28 Tage fürs Ranking. Langsamer LCP kommt meist von unoptimierten Hero-Bildern, render-blockendem JavaScript oder CSS oder langsamen Server-Antwortzeiten.

Interaction to Next Paint (INP)

INP hat First Input Delay (FID) am 12. März 2024 als Core Web Vital ersetzt. INP misst die Latenz aller Nutzerinteraktionen (Klicks, Taps, Tastendrücke) über die gesamte Seitenlebensdauer und meldet die schlechteste (oder nahezu schlechteste, je nach Traffic). Gut: unter 200 ms. Verbesserung nötig: 200–500 ms. Schlecht: über 500 ms. Anders als FID — das nur die erste Interaktion maß — fängt INP jeden Moment ein, in dem ein Nutzer auf etwas klickt und auf Antwort wartet. Schwere JavaScript-Handler, lange Tasks, die den Main Thread blockieren, und unkontrollierte Re-Renders sind die Hauptursachen für schlechte INP.

Cumulative Layout Shift (CLS)

CLS misst die visuelle Stabilität — wie stark die Seite herumspringt, während Inhalte laden. Es ist ein einheitenloser Wert von 0 (perfekt, nichts bewegt sich) bis 1+ (chaotisch). Gut: unter 0,1. Verbesserung nötig: 0,1–0,25. Schlecht: über 0,25. Häufige Ursachen: Bilder ohne explizite width/height-Attribute, Web-Fonts, die ohne Size-Matching umschalten (FOUT), und Werbung oder Embeds, die ohne reservierten Platz in den Document Flow eingefügt werden.

Wie Google Core Web Vitals fürs Ranking nutzt

Seit dem Page-Experience-Update fließen alle drei CWV-Metriken als Teil des breiteren Page-Experience-Signals in Googles Ranking-Algorithmus ein. Um den Page-Experience-Test zu bestehen, muss eine URL bei allen drei Metriken am 75. Perzentil der Real-User-Samples "Gut" erreichen. Seiten, die bestehen, bekommen einen kleinen Ranking-Boost gegenüber vergleichbaren Seiten, die das nicht tun. Wichtig: CWV ist ein Tiebreaker, kein magischer Ranking-Hebel — starke CWV überholen nicht irrelevante Inhalte, aber zwei Seiten mit ähnlicher Relevanz und thematischer Autorität werden die mit besseren CWV vorn sehen.

Mobile und Desktop werden separat bewertet. Die meisten Seiten haben schlechtere CWV auf Mobile (langsamere CPU, langsamere Netzwerke), also ist Mobile meist der Engpass für Ranking-Verbesserungen.

Lab vs. Field: Warum dein Lighthouse-Score lügt

Lighthouse, der Lab-Tab in PageSpeed Insights und ähnliche Tools simulieren ein Gerät in einem schnellen Netzwerk und berechnen synthetische CWV. Echte Nutzer kommen aus Tausenden von Geräten, Netzwerken und Standorten — und ihr CrUX-aggregiertes CWV ist das, was Google fürs Ranking nutzt. Ein Lighthouse-Score von 95 bedeutet nicht, dass dein CrUX-CWV gut ist. Prüfe immer beides: Lab für die Diagnose (was ist langsam, warum), Field für den Ranking-Impact (haben echte Nutzer eine gute Erfahrung).

Der schnellste Weg, deine Live-CrUX-Werte zu sehen, ist der Core-Web-Vitals-Report in der Google Search Console, der den 28-Tage-Field-Rollup pro Seitengruppe zeigt. PageSpeed Insights zeigt auch Field-Daten, wenn CrUX genug Samples für die URL hat.

Häufige Ursachen schlechter Core Web Vitals (und wie man sie behebt)

Schlechter LCP kommt meist von: unoptimierten Hero-Bildern (moderne Formate wie AVIF oder WebP nutzen, explizite width/height setzen, das LCP-Bild preloaden), langsamer Server-Antwortzeit / TTFB (cachen, CDN nutzen, Datenbank-Query für Above-the-Fold-Content optimieren) und render-blockenden Ressourcen (nicht-kritisches CSS/JS deferren, kritisches CSS inlinen).

Schlechter INP kommt meist von: lange laufendem JavaScript auf dem Main Thread (in kleinere Tasks brechen, scheduler.yield oder setTimeout nutzen), schweren Event-Handlern (debounce, Arbeit mit Web-Workern vom Main Thread auslagern) und erzwungenem synchronen Layout in Interaktions-Handlern (DOM-Messungen zuerst lesen, Schreibvorgänge danach batchen).

Schlechter CLS kommt meist von: Bildern ohne explizite Abmessungen (immer width/height-Attribute oder aspect-ratio-CSS setzen), spät ladenden Web-Fonts, die FOUT verursachen (font-display: optional oder size-adjust nutzen), und dynamisch injizierten Ads/Embeds (Platz mit min-height reservieren, bevor Inhalt lädt).

Warum FID ausgemustert wurde und INP ihn ersetzt

First Input Delay (FID) war die ursprüngliche Interaktivitätsmetrik. Sie maß die Verzögerung zwischen dem ersten Klick/Tap und dem Moment, in dem der Browser tatsächlich anfing, den Handler zu verarbeiten. Das Problem: FID maß nur die erste Interaktion und ignorierte alles, was nach dem Laden der Seite passierte. Echte Nutzer klicken viele Dinge während einer Sitzung, und die meisten schmerzhaften Interaktionen passieren mitten in der Session, nicht beim ersten Klick.

INP behebt das, indem es jede Interaktion misst und dann die schlechteste meldet. Der Übergang war offiziell am 12. März 2024 — Seiten, die bei FID gut rankten, sahen plötzlich andere Zahlen in CrUX, als Google die Quellmetrik umstellte. Wenn du vor 2024 nur für FID optimiert hast, sind deine CWV-Scores fast sicher schlechter geworden, ohne dass sich sonst etwas geändert hat.

FAQ: Core Web Vitals

Was sind gute Core-Web-Vitals-Werte 2026?

LCP unter 2,5 s, INP unter 200 ms, CLS unter 0,1 — gemessen am 75. Perzentil von Real-User-Daten über 28 Tage. "Gut" bei allen dreien ist die Schwelle, um das Page-Experience-Signal in Googles Ranking-Algorithmus zu passieren.

Wie lange dauert es, bis CWV-Verbesserungen in der Search Console sichtbar werden?

CrUX ist ein rollierendes 28-Tage-Fenster, also erscheinen heute deployte Änderungen vollständig nach etwa 28 Tagen in deinem CWV-Report. Erwarte teilweise Verbesserungen in der ersten Woche, vollständige Reflektion bis Woche vier. Keine Panik, wenn deine Scores ein paar Tage nach einem Deploy schlechter aussehen — das rollierende Fenster enthält noch meist die alten Daten.

Sind Core Web Vitals wichtig fürs SEO?

Ja — CWV ist ein bestätigtes Google-Ranking-Signal als Teil des Page-Experience-Updates. Der Boost ist klein (eher Tiebreaker als Megafon), aber über Tausende von URLs hinweg zählt es. Wichtiger noch: Dieselben Dinge, die CWV verbessern (schnellere Seiten, weniger Layout-Shift), verbessern auch die Nutzerzufriedenheit und reduzieren die Absprungrate.

Was ist der Unterschied zwischen Lab- und Field-CWV?

Lab: synthetische Messung auf einem Gerät unter kontrollierten Bedingungen (Lighthouse, PageSpeed Insights Lab-Tab). Nützlich für die Diagnose. Field: echte Nutzer in freier Wildbahn, aggregiert von Chrome (CrUX). Das, was Google tatsächlich fürs Ranking nutzt. Dein Lab-Score und Field-Score können stark abweichen — prüfe immer beide.

Kann ich einen hohen Lighthouse-Score haben und trotzdem bei Core Web Vitals durchfallen?

Ja. Lighthouse simuliert ein Gerät in einem Netzwerk. Echte Nutzer verteilen sich auf Tausende von Gerätestufen und Verbindungsgeschwindigkeiten. Eine Seite, die in Lighthouse auf einem M1 MacBook 95 erreicht, kann immer noch durchfallenden Field-LCP von Nutzern auf Mid-Range-Android-Phones in 4G-Regionen haben. CrUX ist die Wahrheit.

Wie kann ich CWV kontinuierlich monitoren?

Drei Quellen, gemeinsam genutzt: Google Search Console (28-Tage-Field-Rollup, pro Seitengruppe), PageSpeed Insights (pro URL Lab + Field) und ein synthetisches Monitoring-Tool, das Lighthouse-Audits von echten Browsern in echten Regionen nach Plan ausführt. LoadFocus macht das dritte — geplante Lighthouse-Audits aus 25+ globalen Regionen, um CWV-Regressionen zu fangen, bevor sie das 28-Tage-CrUX-Fenster erreichen.

Zählt das Laden einer gecachten Seite für CWV?

Ja. CrUX misst jede Navigation in Chrome, einschließlich Reloads und Back-Forward-Navigationen. Bfcache-Treffer — sofortige Wiederherstellung aus dem Verlauf — werden als neue Navigationen mit sehr schnellen Ladezeiten behandelt, was deinen CWV-Durchschnitten generell hilft. Für Bfcache-Berechtigung zu optimieren (keine unload-Handler, kein Cache-Control: no-store) ist einer der billigsten CWV-Gewinne.

Wie LoadFocus mit Core Web Vitals hilft

LoadFocus führt Lighthouse-Audits aus 25+ AWS-Regionen nach Plan aus und zeigt, wie CWV nach Geografie und Tageszeit variieren. Wo dir Google Search Console den 28-Tage-Field-Rollup gibt, sagt dir LoadFocus, was gerade jetzt passiert — und von wo. Kombiniere das synthetische Monitoring mit dem LoadFocus-Website-Speed-Test für einmalige Tiefenanalysen, wenn du eine Änderung shippst. Registriere dich kostenlos auf loadfocus.com/de-de/signup oder führe einen Sofort-Test auf loadfocus.com/de-de/website-speed-test aus.