Core Web Vitals 2026: Neue Metriken und Strategien

Die Core Web Vitals bestehen aus drei Metriken, die gemeinsam die Nutzererfahrung einer Website quantifizieren. Largest Contentful Paint (LCP) misst die Ladegeschwindigkeit – konkret die Zeit, bis das größte sichtbare Element im Viewport vollständig gerendert ist. Interaction to Next Paint (INP) misst die Reaktionsfähigkeit – die Zeit zwischen einer Nutzerinteraktion (Klick, Tippen, Tastendruck) und dem nächsten visuellen Update. Cumulative Layout Shift (CLS) misst die visuelle Stabilität – wie stark sich Seitenelemente während des Ladens unerwartet verschieben.

Jede dieser Metriken hat klar definierte Schwellenwerte: LCP gilt als gut unter 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1. Werte oberhalb dieser Grenzen werden als verbesserungsbedürftig oder schlecht eingestuft (Quelle: Google, 2024). Wichtig: Diese Schwellenwerte basieren auf dem 75. Perzentil der tatsächlichen Nutzerdaten aus dem Chrome UX Report (CrUX). Das bedeutet, dass mindestens 75 % aller Seitenaufrufe den guten Bereich erreichen müssen, damit die Website insgesamt als bestanden gilt.

Die Ablösung von First Input Delay (FID) durch Interaction to Next Paint (INP) im März 2024 war die bedeutendste Änderung an den Core Web Vitals seit ihrer Einführung. FID maß nur die Verzögerung der allerersten Interaktion auf einer Seite – und ignorierte alle nachfolgenden Interaktionen vollständig. Das führte dazu, dass Websites mit einem schnellen ersten Klick, aber langsamer Reaktion auf weitere Aktionen trotzdem gute FID-Werte erzielten. INP schließt diese Lücke: Die Metrik bewertet alle Interaktionen während des gesamten Seitenbesuchs und berichtet die langsamste (oder nahezu langsamste) Interaktion als INP-Wert (Quelle: Google, 2024).

Der Unterschied in der Praxis ist erheblich. Laut einer Analyse von HTTP Archive (2025) haben nach dem Wechsel zu INP nur noch 65 % aller Websites gute Interaktivitätswerte – im Vergleich zu über 93 % mit FID. Besonders betroffen sind Websites mit umfangreichen JavaScript-Frameworks, dynamischen Inhalten und komplexen Event-Handlern. E-Commerce-Shops, Single-Page-Applications und Seiten mit Drittanbieter-Skripten zeigen häufig schlechte INP-Werte, obwohl ihre FID-Werte zuvor im grünen Bereich lagen.

Technisch misst INP drei Phasen jeder Interaktion: die Input Delay (Zeit zwischen der Nutzeraktion und dem Start des Event-Handlers), die Processing Time (Ausführungsdauer des Event-Handlers) und die Presentation Delay (Zeit bis zum nächsten Frame-Rendering). Alle drei Phasen summieren sich zum INP-Wert. Der Schwellenwert von 200 Millisekunden für "gut" ist bewusst ambitioniert gewählt – er stellt sicher, dass Nutzer bei jeder Aktion ein unmittelbares visuelles Feedback erhalten. Wer diesen Wert nicht erreicht, muss seine Frontend-Optimierung grundlegend überdenken.

Largest Contentful Paint bleibt die zentrale Ladezeitmetrik der Core Web Vitals. LCP misst, wann das größte sichtbare Element im initialen Viewport vollständig gerendert ist – typischerweise ein Hero-Bild, ein großes Textblock oder ein Video-Poster. Der Schwellenwert von 2,5 Sekunden gilt als gut, zwischen 2,5 und 4 Sekunden als verbesserungsbedürftig und darüber als schlecht (Quelle: Google, 2024). Laut Web Almanac (2025) erreichen nur 52 % aller Websites einen guten LCP-Wert auf Mobilgeräten.

Die LCP-Optimierung erfordert ein systematisches Vorgehen, das alle Phasen des Ladeprozesses abdeckt. Der erste Schritt ist die Identifikation des LCP-Elements über die Chrome DevTools oder den Performance-Analyzer. Häufig ist das LCP-Element ein Hero-Bild, das erst spät geladen wird, weil es über CSS-Background oder Lazy Loading eingebunden ist. Die Lösung: Das LCP-Bild als -Element mit fetchpriority="high" und loading="eager" einbinden und einen -Hint im setzen.

Weitere LCP-Optimierungen umfassen die Reduktion der Server-Antwortzeit (TTFB unter 800 Millisekunden), die Eliminierung von Render-Blocking Resources durch Critical CSS und asynchrones JavaScript-Loading, die Optimierung von Bildformaten (WebP oder AVIF statt JPEG/PNG) und die Implementierung von Responsive Images mit srcset und sizes. Jede dieser Maßnahmen wirkt sich direkt auf den LCP-Wert aus. In unseren Projekten erreichen wir typischerweise LCP-Verbesserungen von 40–60 % durch eine Kombination dieser Techniken (Projekterfahrung).

Cumulative Layout Shift misst, wie stark sich sichtbare Elemente während des Seitenladens unerwartet verschieben. Ein CLS-Wert unter 0,1 gilt als gut (Quelle: Google, 2024). Layout Shifts entstehen typischerweise durch Bilder ohne definierte Dimensionen, nachladende Web-Fonts, dynamisch eingefügte Werbebanner, Cookie-Consent-Layer ohne reservierten Platz und spät ladende Drittanbieter-Skripte, die DOM-Elemente einfügen.

Die CLS-Optimierung beginnt mit einer grundlegenden Regel: Jedes visuelle Element benötigt reservierte Dimensionen, bevor es vollständig geladen ist. Für Bilder bedeutet das explizite width- und height-Attribute oder die CSS-Property aspect-ratio. Für Schriftarten das Setzen von font-display: swap in Kombination mit einer metrisch kompatiblen Fallback-Schriftart, die denselben Platzbedarf hat. Google empfiehlt seit 2025 die Verwendung von font-display: optional für nicht-kritische Schriftarten, um Layout Shifts durch Font-Swaps vollständig zu eliminieren (Quelle: web.dev, 2025).

Ein häufig übersehener CLS-Verursacher sind dynamische Inhalte über dem Viewport-Fold: Cookie-Banner, Newsletter-Popups oder nachladende Navigationsleisten, die den sichtbaren Inhalt nach unten schieben. Die Lösung ist entweder eine feste Platzreservierung (z. B. ein Platzhalter-Element mit der exakten Höhe des Banners) oder die Positionierung als Overlay (position: fixed), das keinen Einfluss auf den Dokumentenfluss hat. In der technischen Analyse identifizieren wir alle CLS-Verursacher und priorisieren sie nach Impact.

Die Core Web Vitals sind Teil eines größeren Rahmenwerks: Googles Page Experience Signals. Neben den drei Vitals-Metriken fließen weitere Faktoren in die Bewertung ein: HTTPS als Standardprotokoll, Mobilfreundlichkeit (Mobile-Friendly), das Fehlen aufdringlicher Interstitials und eine sichere Browsing-Erfahrung. Seit 2023 werden die Page Experience Signals nicht mehr als separater Rankingfaktor ausgewiesen, sondern fließen zusammen mit hunderten anderen Signalen in das Gesamtranking ein (Quelle: Google Search Central, 2023).

Das bedeutet nicht, dass die Vitals unwichtig geworden sind – im Gegenteil. Google hat 2025 bestätigt, dass Core Web Vitals weiterhin ein relevanter Rankingfaktor sind und dass Websites mit guten Vitals-Werten bei ansonsten gleichwertigen Inhalten bevorzugt werden (Quelle: Google Search Central Blog, 2025). Der praktische Effekt ist messbar: Eine Studie von Searchmetrics (2025) zeigt, dass Websites in den Top-10-Suchergebnissen durchschnittlich 28 % bessere LCP-Werte und 35 % bessere INP-Werte aufweisen als Websites auf den Positionen 11–20.

Für die Optimierungsstrategie bedeutet das: Core Web Vitals allein werden keine schlecht platzierten Seiten in die Top-10 befördern – aber schlechte Vitals-Werte können ansonsten guten Content daran hindern, sein volles Ranking-Potenzial zu erreichen. Der Return on Investment einer Vitals-Optimierung ist besonders hoch für Websites, die bereits über starke Inhalte und Backlinks verfügen, aber bei den technischen Metriken schwächeln.

Ein fundamentales Verständnis für die Optimierung der Core Web Vitals ist die Unterscheidung zwischen Lab-Daten und Field-Daten. Lab-Daten werden in einer kontrollierten Testumgebung erhoben – typischerweise über Lighthouse oder Chrome DevTools – und liefern reproduzierbare Ergebnisse unter standardisierten Bedingungen. Field-Daten stammen von echten Nutzern und werden über den Chrome UX Report (CrUX) aggregiert. Google verwendet ausschließlich Field-Daten für die Rankingbewertung (Quelle: Google, 2024).

Dieser Unterschied hat weitreichende Konsequenzen. Lab-Tests simulieren typischerweise ein Mid-Tier-Mobilgerät mit gedrosselter Netzwerkverbindung – die Ergebnisse sind oft schlechter als die tatsächliche Nutzererfahrung. Umgekehrt können Lab-Tests INP nicht zuverlässig messen, weil keine echten Nutzerinteraktionen stattfinden. Die INP-Werte in Lighthouse sind synthetische Schätzungen, die erheblich von den Field-Daten abweichen können. Für eine belastbare Bewertung sind daher CrUX-Daten unverzichtbar.

Die wichtigsten Mess-Tools im Überblick: PageSpeed Insights kombiniert Lab- und Field-Daten und zeigt den CrUX-Status für die gesamte Origin und einzelne URLs. Google Search Console bietet den Core Web Vitals Report mit Trends über die Zeit und gruppiert URLs nach Status. Die Web Vitals Extension für Chrome misst die Vitals-Werte in Echtzeit beim Browsen. Und die Chrome DevTools Performance-Leiste ermöglicht die detaillierte Analyse einzelner Interaktionen inklusive der drei INP-Phasen. Wir empfehlen eine Kombination aller Tools in der Performance-Analyse.

Die Optimierung von INP erfordert einen anderen Ansatz als die klassische Ladezeitoptimierung. Während LCP primär durch Netzwerk- und Rendering-Optimierungen verbessert wird, hängt INP von der JavaScript-Ausführung auf dem Main Thread ab. Der Main Thread ist der einzige Thread im Browser, der DOM-Updates durchführen kann – und wenn er durch langlaufende JavaScript-Aufgaben blockiert ist, kann er nicht auf Nutzerinteraktionen reagieren.

Die erste Strategie ist das Aufbrechen von Long Tasks. Ein Long Task ist jede JavaScript-Ausführung, die länger als 50 Millisekunden den Main Thread blockiert. Long Tasks verzögern die Input-Verarbeitung und verschlechtern den INP-Wert. Die Lösung: Umfangreiche Operationen in kleinere Chunks aufteilen und zwischen den Chunks dem Browser die Möglichkeit geben, auf wartende Interaktionen zu reagieren. Das scheduler.yield()-API (seit Chrome 129) ermöglicht diese Unterbrechung elegant und ohne Prioritätsverlust.

Die zweite Strategie ist die Reduktion der Event-Handler-Komplexität. Jeder Klick- oder Input-Handler sollte nur das Minimum an Arbeit ausführen, das für ein visuelles Update nötig ist. Aufwändige Berechnungen, API-Calls und DOM-Manipulationen, die nicht sofort sichtbar sein müssen, werden in requestIdleCallback oder setTimeout mit minimaler Verzögerung ausgelagert. Für rechenintensive Operationen bieten Web Workers eine echte Parallelisierung außerhalb des Main Threads.

Die dritte Strategie betrifft Drittanbieter-Skripte. Analytics-Tags, Werbe-Pixel, Chat-Widgets und Social-Media-Embeds fügen dem Main Thread erhebliche Arbeit hinzu und verschlechtern den INP-Wert. Die Lösung: Drittanbieter-Skripte konsequent mit async oder defer laden, Tracking-Events über requestIdleCallback senden und nicht-kritische Skripte erst nach der initialen Seiteninteraktion laden (Intersection Observer oder User-Interaction-basiertes Loading). In unserer technischen Analyse identifizieren wir systematisch, welche Drittanbieter-Skripte den größten negativen Impact auf INP haben.

Ein typisches Optimierungsprojekt zeigt, wie die verschiedenen Maßnahmen zusammenwirken. Der Ausgangszustand eines mittelständischen Online-Shops: LCP bei 4,2 Sekunden (schlecht), INP bei 380 Millisekunden (verbesserungsbedürftig) und CLS bei 0,18 (verbesserungsbedürftig). Keine der drei Metriken erreichte den grünen Bereich. Nach einer umfassenden Analyse identifizierten wir die Hauptursachen und priorisierten die Optimierungsmaßnahmen nach erwarteter Wirkung (Projekterfahrung).

Für den LCP-Wert waren drei Faktoren verantwortlich: ein langsamer Server (TTFB von 1,8 Sekunden), ein Hero-Bild im JPEG-Format ohne Preload-Hint und Render-Blocking CSS von über 180 KB. Die Server-Optimierung mit Opcode-Cache, Datenbankindex-Tuning und CDN-Integration senkte den TTFB auf 380 Millisekunden. Die Konvertierung des Hero-Bildes zu WebP mit Preload und die Extraktion von Critical CSS reduzierten den LCP von 4,2 auf 1,7 Sekunden – eine Verbesserung um 60 %.

Der INP-Wert wurde durch ein jQuery-basiertes Mega-Menü mit komplexen Animationen, einen synchronen API-Call im Warenkorb-Button-Handler und mehrere Tracking-Skripte verursacht. Die Migration des Menüs auf CSS-Transitions, die Asynchronisierung des Warenkorb-API-Calls und die Verlagerung der Tracking-Events in requestIdleCallback senkten den INP von 380 auf 140 Millisekunden. Der CLS wurde durch fehlende Bilddimensionen, einen nachladenden Cookie-Banner und dynamisch eingefügte Produktbewertungen verursacht – nach Behebung aller drei Punkte sank der CLS von 0,18 auf 0,03.

Core Web Vitals sind keine einmalige Aufgabe, sondern erfordern kontinuierliches Monitoring. Neue Inhalte, Plugin-Updates, Design-Änderungen und aktualisierte Drittanbieter-Skripte können jederzeit die Werte verschlechtern. Ein professionelles Monitoring-Setup umfasst automatische Alerts bei Verschlechterungen, regelmäßige Reports und eine historische Trendanalyse. Die Google Search Console bietet einen grundlegenden Core Web Vitals Report – für tiefergehende Analysen empfehlen wir zusätzliche Tools.

Besonders wertvoll ist die Überwachung auf Seitenebene. Die Gesamt-Origin-Bewertung in CrUX kann gut sein, während einzelne Template-Typen schlechte Werte aufweisen. Produktdetailseiten mit vielen Bildern haben oft schlechtere LCP-Werte als die Homepage, Kategorie-Seiten mit umfangreichen Filtern haben schlechtere INP-Werte, und Checkout-Seiten mit dynamischen Formularen zeigen häufig erhöhte CLS-Werte. Eine granulare Überwachung deckt diese Template-spezifischen Probleme auf, bevor sie sich auf das Gesamtranking auswirken.

Ein bewährter Ansatz ist die Kombination aus automatisiertem und manuellem Monitoring. Automatisierte Lab-Tests über Lighthouse CI bei jedem Deployment fangen Regressionen sofort ab. Wöchentliche Field-Data-Checks über die Search Console und PageSpeed Insights zeigen die tatsächliche Nutzererfahrung. Und ein monatlicher manueller Deep-Dive mit den Chrome DevTools Performance-Tools identifiziert subtile Probleme, die automatisierte Tests nicht erfassen – etwa INP-Verschlechterungen durch neue Drittanbieter-Skripte oder CLS-Verschiebungen durch dynamisch geladene Werbebanner. Dieser mehrschichtige Ansatz stellt sicher, dass die Performance-Optimierung nachhaltig wirkt und nicht durch nachträgliche Änderungen zunichte gemacht wird.

Für die langfristige Qualitätssicherung empfehlen wir die Integration von Performance-Budgets in den Entwicklungsprozess. Ein Performance-Budget definiert Obergrenzen für JavaScript-Bundle-Größen, CSS-Dateien, Bildgrößen und die Anzahl der HTTP-Requests. Wird ein Budget überschritten, schlägt der Build-Prozess fehl und verhindert die Veröffentlichung von Performance-Regressionen. Tools wie Lighthouse CI integrieren sich nahtlos in CI/CD-Pipelines und automatisieren diese Prüfung bei jedem Deployment. In unseren Projekten richten wir diese Budgets als Teil der Performance-Strategie ein.

Google hat angekündigt, die Core Web Vitals kontinuierlich weiterzuentwickeln. Mögliche zukünftige Metriken, die derzeit erforscht werden, umfassen Smoothness (wie flüssig sich Animationen und Scrolling anfühlen), Long Animation Frames (LoAF) als detailliertere Diagnose-Metrik für INP-Probleme und verbesserte Messungen für die Ladezeit von Soft Navigations in Single-Page-Applications (Quelle: web.dev, 2025). Während diese Metriken noch nicht in die Ranking-Bewertung einfließen, lohnt es sich, die Entwicklung zu beobachten.

Ein weiterer Trend ist die zunehmende Bedeutung von Mobile-Performance. Google bewertet Websites primär anhand der mobilen Version (Mobile-First Indexing) und die Schwellenwerte der Core Web Vitals sind auf mobile Geräte ausgelegt. Mit der wachsenden Verbreitung von 5G verbessern sich zwar die Netzwerkbedingungen, aber die Rechenleistung mobiler Geräte in mittleren und unteren Preissegmenten bleibt begrenzt. Die INP-Optimierung ist daher besonders für mobile Nutzer mit schwächerer Hardware relevant.

Zusammenfassend bleibt die Strategie klar: Websites, die heute in alle drei Core Web Vitals investieren und ein kontinuierliches Monitoring etablieren, sind für zukünftige Änderungen an den Metriken und Schwellenwerten am besten aufgestellt. Die Grundprinzipien – schnelles Laden, reaktionsfähige Interaktionen und stabile Layouts – werden unabhängig von konkreten Metriken immer relevant bleiben. Eine professionelle Performance-Optimierung zahlt sich nicht nur im Ranking aus, sondern direkt in besserer Nutzererfahrung und höheren Conversion-Raten.