Core Web Vitals verbessern: LCP, INP und CLS in der Praxis

Wenn die Google Search Console meldet, dass Seiten deiner Website "schlechte" Core Web Vitals haben, folgt schnell die Frage: Was genau ist betroffen, wo beginnt die Ursachensuche, und in welcher Reihenfolge lohnt sich die Arbeit? Dieser Artikel beantwortet genau das. Als Orientierung vorab: Als gut gelten laut Google ein LCP unter 2,5 Sekunden, ein INP unter 200 Millisekunden und ein CLS unter 0,1. Wie du Seiten, die diese Werte nicht erreichen, gezielt diagnostizierst und verbesserst, zeigen die folgenden Abschnitte zu den drei Core Web Vitals.

Eine Abgrenzung vorab: Core Web Vitals messen die Nutzererfahrung, nicht die allgemeine Ladezeit. Caching-Strategien, Server-Konfiguration und die Reduzierung von HTTP-Anfragen sind Pagespeed-Themen, die in einem gesonderten Artikel behandelt werden. Hier geht es ausschließlich um die drei Kennzahlen selbst, ihre Grenzwerte und die jeweils typischen Fixes.

Was die drei Kennzahlen messen

Google hat die Core Web Vitals als Teil des Page Experience Updates im Mai 2021 als Rankingsignale eingeführt (Google Search Central, 2021). Seit März 2024 besteht das Trio aus:

• LCP (Largest Contentful Paint): Wie lange dauert es, bis das größte sichtbare Element im Viewport gerendert ist? In den meisten Fällen ist das das Hero-Bild oder ein großer Textblock oberhalb der Falzkante.
• INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf eine Nutzereingabe, also einen Klick, Tap oder Tastendruck? INP hat im März 2024 den früheren FID (First Input Delay) als offizielle Core Web Vital abgelöst (web.dev, 2024).
• CLS (Cumulative Layout Shift): Wie stark verschieben sich Seitenelemente unerwartet während des Ladens oder danach?

Die Grenzwerte, die Google als "gut" einstuft, lauten (web.dev, 2023): LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1. Als "verbesserungsbedürftig" gelten LCP zwischen 2,5 und 4 Sekunden, INP zwischen 200 und 500 Millisekunden sowie CLS zwischen 0,1 und 0,25. Alles darüber ist "schlecht".

Der Wechsel von FID zu INP ist für viele Teams folgenreicher als er zunächst klingt. FID maß nur die Latenz der allerersten Interaktion auf einer Seite. INP bewertet dagegen jede Interaktion und wählt den schlechtesten gemessenen Wert. Eine Seite, die beim ersten Klick schnell reagiert, aber bei einem späteren Menüklick 600 Millisekunden braucht, erhält deshalb einen INP-Wert von 600 ms und landet damit deutlich im roten Bereich.

Den Status in der Google Search Console ablesen

Die Search Console ist der richtige Ausgangspunkt, weil sie auf Felddaten aus echten Chrome-Nutzern basiert (dem sogenannten Chrome UX Report, kurz CrUX), nicht auf Labormessungen. Zum CWV-Bericht gelangt man über den Menüpunkt Erfahrung > Core Web Vitals. Dort gibt es zwei Tabs: Mobil und Desktop. In der Praxis zeigt der mobile Tab häufiger Probleme, weil Mobilgeräte langsamere Prozessoren und wechselhafte Netzwerkverbindungen haben.

Der Bericht gruppiert URLs nach dem gemeinsamen Problem. "Schlechte URLs" liegen in der roten Zone, "verbesserungsbedürftige URLs" in der gelben. Ein Klick auf eine Gruppe zeigt, welche Kennzahl ursächlich ist und welche konkreten Seiten betroffen sind. Das ist der Startpunkt für die Priorisierung.

Ein häufiges Missverständnis: Seiten mit wenig Traffic erscheinen oft gar nicht im Bericht, weil Google mindestens eine bestimmte Anzahl an Felddatenpunkten benötigt, bevor er eine URL auswertet. Für diese Seiten empfiehlt sich PageSpeed Insights, das dieselbe Metrik-Logik verwendet, aber auch für einzelne URLs ohne ausreichend CrUX-Daten eine Einschätzung liefert.

LCP verbessern: Das Hauptbild als häufigster Schwachpunkt

In den meisten Fällen ist das größte sichtbare Element im Viewport ein Bild. Die häufigsten Ursachen für einen schlechten LCP-Wert:

• Langsame Server-Antwortzeit (Time to First Byte, kurz TTFB)
• Render-blockierendes JavaScript oder CSS, das den Browser aufhält, bevor er das Element laden kann
• Das LCP-Bild wird im HTML zu spät entdeckt und deshalb verspätet heruntergeladen
• Das Bild ist zu groß oder liegt in einem veralteten Format vor

Der wirkungsvollste Einzeiler für die meisten Websites: Das LCP-Bild im HTML mit dem Attribut fetchpriority="high" versehen. Damit signalisiert man dem Browser, dieses Bild sofort herunterzuladen, bevor andere Ressourcen an die Reihe kommen. Kombiniert mit modernen Bildformaten wie WebP oder AVIF lässt sich der LCP-Wert in vielen Fällen deutlich senken.

Wer mit einem modernen Website-Builder arbeitet, hat hier oft einen strukturellen Vorteil. Webflow-Websites für Unternehmen liefern schlankes, semantisch korrektes HTML und komprimieren Bilder automatisch, was LCP und CLS seltener zur Fehlerquelle macht als bei WordPress-Setups mit vielen Plugins, die Render-Blocking-Ressourcen einschleusen.

Weitere Maßnahmen für Seiten, bei denen das LCP-Element kein Bild, sondern ein Textblock ist: Schriften mit <link rel="preload" as="font"> vorladen und kritisches CSS direkt im <head> einbetten, damit der Browser nicht auf eine externe CSS-Datei warten muss, bevor er mit dem Rendern beginnt.

INP verbessern: Die neue Kennzahl für Interaktivität

INP ist die Kennzahl, mit der sich viele Teams am schwersten tun, weil sie sich nicht durch bessere Bilder oder schnelleres Hosting lösen lässt. Ein hoher INP-Wert zeigt fast immer, dass JavaScript-Aufgaben auf dem Haupt-Thread zu lang laufen. Der Browser kann während dieser Aufgaben nicht auf Nutzereingaben reagieren, weshalb ein Klick ins Leere zu führen scheint.

Das Werkzeug der Wahl für die Diagnose: Chrome DevTools, Tab "Performance". Dort sind sogenannte Long Tasks als rote Markierungen erkennbar. Als Long Task gilt laut Google jede Aufgabe, die länger als 50 Millisekunden auf dem Haupt-Thread läuft (web.dev, 2023). Typische Verursacher sind Analytics-Skripte, Live-Chat-Widgets und A/B-Testing-Tools, die beim Laden oder bei Klick-Events umfangreichen Code ausführen. Wer den technischen Unterbau einer Seite systematisch prüfen will, findet im Onpage-SEO-Leitfaden eine strukturierte Checkliste, die von Crawlability über Ladezeit bis zu Interaktivitätssignalen reicht.

Konkrete Ansätze zur INP-Verbesserung:

• Long Tasks aufteilen: Statt einer Funktion, die 300 ms am Stück läuft, mehrere kleinere Aufgaben mit setTimeout() oder dem neueren scheduler.yield() ausführen. Der Browser kann so zwischen den Teilaufgaben auf Eingaben reagieren.
• Drittanbieter-Skripte prüfen und reduzieren: Jedes externe Skript, also Tag-Manager-Einträge, Pixel oder Widgets, sollte konkret begründbar sein. Skripte, die nur auf bestimmten Seiten gebraucht werden, nur dort laden.
• Event-Handler schlank halten: Klick-Handler, die komplexe DOM-Manipulationen oder synchrone Netzwerkanfragen auslösen, sind ein häufiger INP-Verursacher. Prüfen, ob ein Teil der Logik in einen Web Worker oder einen asynchronen Callback verschoben werden kann.

CLS verbessern: Layout-Sprünge auf null bringen

CLS ist die Kennzahl, bei der die häufigste Ursache auch am einfachsten zu beheben ist. Wenn der Browser die Dimensionen eines Bildes oder Videos nicht im HTML vorfindet, reserviert er keinen Platz dafür. Sobald das Element geladen ist, verschiebt sich alles darunter. Das erzeugt einen messbaren CLS-Wert und irritiert Nutzer, die gerade lesen oder tippen.

Die Lösung ist einfach: Jedes <img>- und <video>-Element sollte width und height als Attribute im HTML-Code haben. Moderne Frameworks setzen das inzwischen automatisch, ältere CMS-Themes und Drittanbieter-Plugins jedoch nicht immer.

Weitere CLS-Verursacher, die in der Praxis häufig übersehen werden:

• Dynamisch nachgeladene Inhalte ohne Platzhalter: Cookie-Banner, Werbeplätze und eingebettete Inhalte, die erst nach dem ersten Rendern erscheinen, verschieben beim Einblenden den gesamten Seiteninhalt. Sie benötigen einen Container mit einer festen Mindesthöhe, damit der Platz bereits beim ersten Rendern reserviert ist.
• Web-Schriften mit zu wenig Fallback-Planung: Wenn eine Custom-Font später lädt und mehr Platz braucht als die Fallback-Schrift, entsteht ein sichtbares Rucken. font-display: swap verhindert das unsichtbare Warten auf die Schrift, kann aber selbst einen kleinen Shift erzeugen. font-display: optional ist die striktere Wahl, wenn CLS oberhalb des Grenzwerts liegt: Der Browser verzichtet dann komplett auf einen Fallback-Flash und wartet beim ersten Load kurz, ob die Schrift rechtzeitig kommt.
• Lazy-geladene Bilder ohne Aspect-Ratio-CSS: Bilder, die erst beim Scrollen geladen werden, brauchen denselben Platz wie normale Bilder. Eine aspect-ratio-CSS-Eigenschaft oder feste width/height-Attribute im HTML-Code lösen das Problem, ohne auf Lazy Loading verzichten zu müssen.

Welche Kennzahl hat Vorrang? Eine Entscheidungshilfe

Die Search Console zeigt oft Probleme bei mehreren Kennzahlen gleichzeitig. Wer alle drei auf einmal angeht, verliert schnell den Überblick darüber, welche Maßnahme welchen Effekt hatte. Die folgende Tabelle gibt eine Orientierung, basierend auf typischen Symptommustern:

Symptom in der Search ConsoleWahrscheinliche UrsacheErster SchrittLCP-Probleme, vor allem auf MobilgerätenHero-Bild nicht priorisiert oder zu großfetchpriority="high" am LCP-Bild setzen; Dateiformat und -größe prüfenINP-Warnungen auf interaktiven Seiten (Formulare, Filter, Navigation)Lange JavaScript-Aufgaben blockieren den Haupt-ThreadChrome DevTools, Performance-Tab öffnen; Long Tasks über 50 ms identifizierenCLS auf Content-Seiten, bereits beim ersten Laden sichtbarBilder ohne Dimensionen im HTMLAlle <img>-Tags auf fehlende width/height-Attribute prüfenCLS nach dem ersten Laden, beim Scrollen oder nach InteraktionDynamisch nachgeladene Inhalte oder Web-Fonts ohne PlatzhalterCookie-Banner und Werbeplätze mit fester Mindesthöhe versehen; font-display-Wert prüfen

Eine Orientierung, die sich in der Praxis häufig bewährt: LCP und CLS lassen sich oft ohne direkten Entwicklungszugriff verbessern, zum Beispiel über Einstellungen im CMS oder im Page-Builder. INP dagegen erfordert fast immer Einblick in den JavaScript-Code. Wenn kein Entwickler-Zugang vorhanden ist, ist es sinnvoll, LCP und CLS zuerst anzugehen und INP als separaten Schritt zu planen.

Wer den Schritt von einer CMS-basierten Website zu einer modernen Architektur erwägt, um von Haus aus bessere Performance-Ausgangswerte zu bekommen, findet einen nüchternen Vergleich der Plattformen im Artikel zu Framer vs. Webflow, der auch auf unterschiedliche Rendering-Architekturen und deren Auswirkung auf Core Web Vitals eingeht.

Core Web Vitals als kontinuierliche Aufgabe

Core Web Vitals sind kein einmaliges Projekt. Google aktualisiert die Grenzwerte und führt neue Metriken ein, wie der Wechsel von FID zu INP im März 2024 gezeigt hat. In den Suchergebnisseiten (SERP) behandelt Google Performance-Daten aus echten Nutzersessions als ein Qualitätssignal, das sich von reinen Inhaltssignalen grundlegend unterscheidet. Ob und wie stark das Gewicht dieses Signals in Zukunft steigt, lässt sich nicht vorhersagen.

Der Ablauf bleibt immer derselbe: messen (Search Console, PageSpeed Insights), Hauptursache je Kennzahl identifizieren, Maßnahmen umsetzen und einige Wochen warten, bis sich neue Felddaten in der Search Console niederschlagen. Typischerweise dauert es vier bis acht Wochen, bis eine technische Änderung vollständig in den CrUX-Daten der Search Console sichtbar wird, da Google einen rollierenden 28-Tage-Durchschnitt über echte Chrome-Nutzerdaten berechnet (Google Search Central, 2024).