Core Web Vitals optimieren: LCP, INP und CLS verbessern (2026)

Core Web Vitals optimierst du in drei Schritten: Zuerst schaust du in die Felddaten (Search Console oder PageSpeed Insights), dann findest du heraus, welche der drei Metriken LCP, INP oder CLS schlecht ist, und erst danach änderst du Code. Gut ist eine Seite, wenn 75 % der Seitenaufrufe einen LCP bis 2,5 Sekunden, einen INP bis 200 Millisekunden und einen CLS bis 0,1 erreichen.

Die meisten Probleme haben wenige Ursachen: ein zu großes oder zu spät geladenes Hero-Bild, zu viel JavaScript im Main-Thread und Elemente ohne reservierten Platz. Dieser Artikel zeigt, wie du die Werte richtig liest und an welchen Stellen du ansetzt. Alle Angaben beziehen sich auf die Dokumentation von Google und web.dev, Stand Oktober 2026.

Was sind Core Web Vitals?

Core Web Vitals sind drei Messwerte, mit denen Google die Nutzererfahrung einer Seite bewertet: Largest Contentful Paint (LCP) für die Ladezeit des größten sichtbaren Elements, Interaction to Next Paint (INP) für die Reaktion auf Klicks und Eingaben und Cumulative Layout Shift (CLS) für die visuelle Stabilität.

Die drei Kernmetriken LCP, INP und CLS mit ihren Grenzwerten.

Die Grenzwerte laut web.dev:

Wichtig ist der Bezugspunkt: Google bewertet das 75. Perzentil der echten Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Ein einzelner schneller Test auf deinem Rechner sagt darüber wenig aus.

Warum INP das alte FID ersetzt hat

Am 12. März 2024 hat INP die Metrik First Input Delay (FID) als Core Web Vital abgelöst. FID hat nur die Wartezeit bei der allerersten Interaktion gemessen, also bis der Browser überhaupt anfangen konnte, den Klick zu verarbeiten. Was danach passierte, blieb unsichtbar.

INP misst laut web.dev alle Klicks, Taps und Tastatureingaben während des gesamten Seitenbesuchs. Scrollen und Hover zählen nicht. Jede Interaktion besteht aus drei Phasen, die zusammen die Latenz ergeben:

• Input Delay: Wartezeit, weil der Main-Thread noch mit etwas anderem beschäftigt ist
• Processing Duration: Laufzeit der Event-Handler
• Presentation Delay: Zeit, bis der Browser das nächste Bild zeichnet

Als INP-Wert zählt im Wesentlichen die langsamste Interaktion. Bei Seiten mit vielen Interaktionen ignoriert Google pro 50 Interaktionen den schlechtesten Ausreißer. Viele Seiten, die mit FID grün waren, sind mit INP deshalb gelb oder rot geworden.

Labordaten und Felddaten: Was zählt für Google?

Für das Ranking zählen nur Felddaten, also Messungen echter Chrome-Nutzer aus dem Chrome User Experience Report (CrUX). Labordaten aus Lighthouse oder dem PageSpeed-Insights-Score sind simulierte Einzeltests. Sie eignen sich zum Debuggen, fließen aber nicht in die Bewertung ein.

Warum lokale Tests oft von den echten Nutzerdaten abweichen.

Der Unterschied ist oft groß. Ein Entwickler-Laptop im Büro-WLAN lädt eine Seite in Sekundenbruchteilen, ein drei Jahre altes Android-Handy im Mobilfunknetz braucht ein Vielfaches. Dazu kommt: INP gibt es im Labor gar nicht, weil dort niemand klickt. Lighthouse zeigt stattdessen Total Blocking Time (TBT) als Näherung.

Drei Eigenschaften der CrUX-Daten solltest du kennen:

• 28-Tage-Fenster: PageSpeed Insights und Search Console zeigen einen gleitenden Durchschnitt über 28 Tage. Eine Verbesserung von heute ist erst nach etwa vier Wochen vollständig sichtbar.
• Mindestmenge an Traffic: Seiten mit wenig Besuchern haben keine eigenen Felddaten. Google greift dann auf Werte der ganzen Domain oder ähnlicher URL-Gruppen zurück.
• Nur Chrome: Safari- und Firefox-Nutzer fehlen in CrUX komplett.

Core Web Vitals messen: Welche Tools du brauchst

Für die Messung reichen kostenlose Google-Tools. PageSpeed Insights zeigt Felddaten und Labortest für eine einzelne URL, die Search Console fasst Felddaten für die ganze Website zusammen, und die Chrome DevTools helfen beim Debuggen im Browser.

Welches Tool für welche Frage.

• Search Console, Bericht “Core Web Vitals”: Gruppiert ähnliche URLs, zum Beispiel alle Produktseiten. So siehst du, ob ein Problem an einem Template hängt statt an einer einzelnen Seite. Hier fängst du an.
• PageSpeed Insights: Oben die Felddaten der URL (falls genug Traffic), darunter der Lighthouse-Labortest mit konkreten Hinweisen, etwa welches Element das LCP-Element ist.
• Chrome DevTools, Panel “Performance”: Zeigt Live-Werte für LCP, INP und CLS, während du die Seite bedienst, und vergleicht sie mit den CrUX-Daten. Jede Interaktion wird in ihre drei INP-Phasen zerlegt. Die frühere Chrome-Erweiterung “Web Vitals” hat Google im Januar 2025 eingestellt, ihre Funktionen stecken laut Chrome-Blog jetzt in diesem Panel.

Felddaten zeigen, was echte Nutzer erleben.

Eigene Messung mit Real User Monitoring

Wenn du nicht vier Wochen auf CrUX warten willst oder genau wissen musst, welches Element und welcher Klick das Problem verursacht, misst du selbst. Die offizielle Bibliothek web-vitals von Google erfasst LCP, INP und CLS im Browser deiner Besucher und schickt die Werte an einen eigenen Endpunkt oder dein Analytics-Tool. Der Attribution-Build liefert zusätzlich das verantwortliche Element und das Script.

Seit Safari 26.2 (Dezember 2025) und Firefox 144 lassen sich LCP und INP auch in diesen Browsern messen, CLS weiterhin nur in Chromium-Browsern. Für das Google-Ranking ändert das nichts, CrUX bleibt Chrome-only. Für deine eigene Analyse bekommst du aber erstmals ein Bild deiner iPhone-Nutzer.

Wer bereits PostHog als Analytics-Tool nutzt, kann Web Vitals dort mit erfassen und mit Session Replays verknüpfen. Bei Messungen über Analytics gilt in Österreich und Deutschland: Ohne Einwilligung keine personenbezogenen Daten senden.

Wie stark beeinflussen Core Web Vitals das Ranking?

Core Web Vitals fließen in das Google-Ranking ein, aber mit begrenztem Gewicht. Google schreibt in der Search-Central-Dokumentation, dass gute Werte dem entsprechen, was die Ranking-Systeme belohnen wollen. Gleichzeitig betont Google, dass relevanter Inhalt Vorrang hat, auch wenn die Seitenerfahrung schwächer ist.

In der Praxis heißt das: Grüne Werte bringen eine schwache Seite nicht auf Platz 1. Bei vergleichbaren Inhalten können sie den Unterschied machen. Den größeren Effekt haben Ladezeit und Stabilität meist auf das Verhalten der Besucher.

Die bekannteste Studie dazu ist “Milliseconds Make Millions” von Deloitte (2020, im Auftrag von Google). Bei 37 Marken stieg die Conversion-Rate im Einzelhandel um 8,4 %, wenn die mobile Ladezeit um 0,1 Sekunden sank. Die Studie zeigt einen Zusammenhang, keinen Beweis für Ursache und Wirkung, und sie nutzt ältere Metriken. Die Richtung ist trotzdem eindeutig.

LCP verbessern: Das größte Element schneller laden

LCP verbesserst du, indem das größte sichtbare Element (meist das Hero-Bild oder eine große Überschrift) so früh wie möglich geladen und gezeichnet wird. Die Ladezeit lässt sich in vier Teile zerlegen: Serverantwort (TTFB), Wartezeit bis zum Start des Bild-Downloads, Download und Rendern. Die DevTools zeigen dir, welcher Teil bei deiner Seite dominiert.

Die häufigsten Ursachen und Lösungen:

• Hero-Bild mit Lazy Loading: Der häufigste Fehler. loading="lazy" gehört nur auf Bilder unterhalb des sichtbaren Bereichs. Das LCP-Bild bekommt stattdessen fetchpriority="high".
• Bild wird spät entdeckt: Wenn das Bild erst per JavaScript oder als CSS-Hintergrund geladen wird, findet der Browser es spät. Besser ist ein normales <img> im HTML oder ein <link rel="preload"> im Head.
• Bild zu groß: Moderne Formate (WebP, AVIF) und srcset mit passenden Größen sparen oft mehr als die Hälfte der Dateigröße.
• Langsamer Server: Wenn die TTFB schon über einer Sekunde liegt, hilft Bildoptimierung wenig. Dann geht es um Caching, ein CDN oder statisches Ausliefern.
• Render-blockierendes CSS und Webfonts: Große CSS-Dateien und Fonts im Head verzögern das erste Zeichnen. Kritisches CSS inline, Fonts selbst hosten und mit font-display: swap laden.

INP verbessern: Den Main-Thread entlasten

INP verbesserst du, indem der Main-Thread des Browsers schneller frei wird. Jede JavaScript-Aufgabe, die länger als 50 Millisekunden läuft, gilt als Long Task und blockiert die Reaktion auf Klicks. Ziel ist, dass nach einer Interaktion zuerst das sichtbare Feedback gezeichnet wird und Nebenarbeit später läuft.

Die wirksamsten Hebel:

• Lange Aufgaben aufteilen: Rechenintensive Arbeit in kleine Blöcke zerlegen und dazwischen an den Browser zurückgeben (Yielding). In Chrome und Firefox geht das mit scheduler.yield(), als Fallback mit setTimeout(..., 0).
• Erst zeichnen, dann rechnen: Im Event-Handler zuerst den sichtbaren Zustand ändern (Button deaktivieren, Spinner zeigen) und Tracking, Speichern oder Neuberechnungen danach ausführen.
• Drittanbieter-Scripts prüfen: Chat-Widgets, Tag-Manager-Container, A/B-Testing-Tools und Werbe-Scripts sind häufig die eigentlichen Verursacher. Was nicht gebraucht wird, fliegt raus. Der Rest lädt später.
• Weniger JavaScript ausliefern: Code-Splitting und das Entfernen ungenutzter Bibliotheken senken die Parse- und Ausführungszeit, vor allem auf schwachen Handys.
• Große DOM-Updates vermeiden: Ein Klick, der tausende Elemente neu rendert, wird langsam. Lange Listen virtualisieren, unnötige Re-Renders in React oder Vue verhindern.

Bei gewachsenen Systemen sitzt das Problem oft tief in der Architektur. Dann reicht ein Plugin nicht mehr, und eine gezielte Software-Modernisierung ist der ehrlichere Weg.

CLS verhindern: Platz reservieren

CLS verhinderst du, indem jedes Element seinen Platz schon beim ersten Rendern bekommt. Layout-Verschiebungen entstehen, wenn Inhalte nachträglich erscheinen und bestehende Inhalte verdrängen. Verschiebungen innerhalb von 500 Millisekunden nach einer Nutzereingabe zählen nicht, weil sie erwartet sind.

Die typischen Ursachen:

• Bilder und Videos ohne Größe: width und height im HTML setzen. Der Browser berechnet daraus das Seitenverhältnis und reserviert den Platz, auch bei responsiven Bildern. Für Container ohne festes Bild hilft die CSS-Eigenschaft aspect-ratio.
• Werbung, Embeds und Cookie-Banner: Für nachgeladene Elemente einen Platzhalter mit min-height reservieren. Cookie-Banner als Overlay anzeigen statt Inhalte nach unten zu schieben.
• Webfonts: Wenn die Ersatzschrift andere Maße hat als die Webfont, springt der Text beim Wechsel. size-adjust und verwandte Eigenschaften in @font-face gleichen die Maße an, Preloading der wichtigsten Schrift verkürzt das Zeitfenster.
• Animationen: Nur transform und opacity animieren. Animationen von top, height oder margin verschieben das Layout.

Framework-Hinweise: Next.js, Astro und WordPress

Moderne Frameworks nehmen dir einen Teil der Arbeit ab, aber nicht automatisch an der richtigen Stelle.

• Next.js: Die next/image-Komponente setzt Größen, liefert WebP aus (AVIF nach Konfiguration) und lädt Bilder standardmäßig lazy. Für das LCP-Bild musst du das aktiv abschalten. Seit Next.js 16 heißt die Eigenschaft dafür preload, das frühere priority ist laut Next.js-Dokumentation veraltet.
• Astro: Liefert standardmäßig statisches HTML ohne JavaScript aus. JavaScript kommt nur dort hin, wo du eine interaktive Komponente einbindest. Das macht gute INP-Werte deutlich einfacher. Diese Website läuft auch auf Astro.
• WordPress: Hier liegen die Probleme meist bei Page-Buildern, vielen Plugins und Drittanbieter-Scripts. Ein Caching-Plugin verbessert vor allem die Serverantwort. Gegen hohe INP-Werte durch schweres JavaScript hilft es kaum.

Wann du Hilfe brauchst

Viele Verbesserungen schaffst du selbst: Hero-Bild korrekt laden, Bildgrößen setzen, unnötige Scripts entfernen. Schwierig wird es, wenn die Ursachen in der Architektur liegen. Typische Anzeichen:

• INP bleibt rot, obwohl Plugins und Caching aktiv sind
• Das Problem steckt im eigenen Frontend-Code einer Web-App, nicht in einem Theme
• Felddaten und Labordaten widersprechen sich, und du findest die Ursache nicht

Dann lohnt sich ein Blick von außen. In unserer Webentwicklung bauen wir Websites und Web-Apps so, dass gute Core Web Vitals von Anfang an eingeplant sind, statt sie später zu reparieren.

Häufige Fragen zu Core Web Vitals

Was bedeutet die Core-Web-Vitals-Bewertung in der Search Console?

Die Search Console teilt deine URLs anhand der Felddaten in “Gut”, “Optimierung erforderlich” und “Langsam” ein, getrennt für Mobilgeräte und Desktop. Eine URL-Gruppe ist nur dann gut, wenn alle drei Metriken im 75. Perzentil gut sind. Die schlechteste Metrik bestimmt die Einstufung.

Wie kann ich Core Web Vitals messen?

Am einfachsten mit PageSpeed Insights für eine einzelne URL und dem Core-Web-Vitals-Bericht in der Google Search Console für die ganze Website. Beide zeigen echte Nutzerdaten aus den letzten 28 Tagen. Zum Debuggen nutzt du das Performance-Panel der Chrome DevTools.

Sind Core Web Vitals ein Rankingfaktor?

Ja. Google nutzt Core Web Vitals seit dem Page-Experience-Update 2021 als Teil der Ranking-Systeme. Das Gewicht ist aber begrenzt: Relevanter Inhalt schlägt gute Ladezeiten. Der größere Nutzen liegt meist bei Absprungrate und Conversion.

Warum ist mein PageSpeed-Score gut, die Search Console aber rot?

Der Score oben in PageSpeed Insights ist ein Labortest unter simulierten Bedingungen. Die Search Console zeigt Felddaten echter Nutzer, oft auf langsameren Geräten. Außerdem misst der Labortest kein INP. Entscheidend für Google sind die Felddaten.

Wie lange dauert es, bis Verbesserungen sichtbar sind?

In den Felddaten etwa 28 Tage, weil PageSpeed Insights und Search Console einen gleitenden Zeitraum zeigen. In der Search Console kannst du nach einer Korrektur die Validierung starten, die ebenfalls rund 28 Tage beobachtet.

Fazit

Core Web Vitals zu optimieren heißt vor allem: zuerst die Felddaten lesen, dann gezielt die eine Metrik angehen, die rot ist. Beim LCP ist es meist das Hero-Bild, beim INP zu viel JavaScript, beim CLS fehlender Platz für nachgeladene Elemente. Prüf deine Seiten im Core-Web-Vitals-Bericht der Search Console, fang beim Template mit den meisten betroffenen URLs an und miss nach vier Wochen erneut.