Core Web Vitals verstehen und verbessern: Was LCP, INP und CLS messen, wie Google sie nutzt und wo Sie zuerst ansetzen

Kaum ein SEO-Thema wird so oft auf eine einzige Zahl reduziert wie die Seitengeschwindigkeit: Der Lighthouse-Score steht auf 62, also muss etwas passieren. Die Core Web Vitals messen aber nicht, wie gut eine Seite im Labor abschneidet, sondern wie echte Besucher sie erleben – und genau diese Unterscheidung entscheidet darüber, ob Ihre Optimierung etwas bringt.

Dieser Leitfaden erklärt, was die drei Messwerte LCP, INP und CLS bedeuten, welche Schwellenwerte gelten, was Google offiziell zur Rolle im Ranking sagt und mit welchen Maßnahmen Sie jeden Messwert gezielt verbessern. Ein eigener Abschnitt zeigt, welche Ladezeit-Hebel jenseits der drei Messwerte zählen.

Vertiefung: Technical SEO bei YellowFrog · SEO-Audit

Was die Core Web Vitals sind

Die Core Web Vitals sind drei standardisierte Messwerte, die beschreiben, wie schnell eine Seite lädt, wie zügig sie auf Eingaben reagiert und wie ruhig ihr Layout bleibt.

Laut web.dev durchlaufen Messwerte einen festen Lebenszyklus von „experimentell“ über „ausstehend“ bis „stabil“. Stabile Core Web Vitals ändern sich höchstens einmal pro Jahr. Genau das ist mit dem früheren Messwert First Input Delay (FID) geschehen: Interaction to Next Paint wurde 2024 zum stabilen Core Web Vital und hat FID abgelöst. Die offizielle Ankündigung auf web.dev ist auf den 12. März 2024 datiert; Anwendungen, die FID-Daten über die Schnittstellen von CrUX oder PageSpeed Insights auslasen, hatten bis zum 9. September 2024 Zeit für die Umstellung.

Für alle drei Werte gelten Schwellenwerte, die web.dev und der Core-Web-Vitals-Bericht der Search Console einheitlich verwenden:

Wichtig ist der Bezugspunkt: Gemessen wird laut web.dev das 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Eine Seite besteht die Bewertung also, wenn mindestens drei Viertel der Besuche einen guten Wert erreichen – ein einzelner schneller Test auf dem Firmenrechner sagt darüber wenig aus. Da die mobile Auswertung getrennt erfolgt und Smartphones oft langsamer sind, lohnt sich der Blick auf die mobilen Werte zuerst.

Was Google zur Rolle im Ranking sagt

Die Core Web Vitals fließen laut Google in das Ranking ein, sind aber ausdrücklich kein Ersatz für relevante, hilfreiche Inhalte.

Auf der Seite zur Seitenerfahrung in der Google-Suche formuliert Google mehrere Aussagen, die zusammen ein klares Bild ergeben:

• Die Core Web Vitals werden von den Ranking-Systemen verwendet. Andere Aspekte der Seitenerfahrung helfen laut Google darüber hinaus nicht direkt dabei, höher zu ranken.
• Ein einzelnes „Seitenerfahrungs-Signal“ gibt es nicht. Die Kernsysteme betrachten verschiedene Signale, die zu einer insgesamt guten Seitenerfahrung passen.
• Die Google-Suche will immer die relevantesten Inhalte zeigen, auch wenn die Seitenerfahrung nicht optimal ist. Gibt es viele hilfreiche Inhalte zu einer Suchanfrage, kann eine gute Seitenerfahrung zum Erfolg beitragen.
• Gute Werte garantieren kein Top-Ranking, und eine perfekte Punktzahl nur aus SEO-Gründen anzustreben, ist laut Google möglicherweise nicht die beste Nutzung Ihrer Zeit.

In der Dokumentation zu den Core Web Vitals empfiehlt Google Website-Betreibern dennoch ausdrücklich, gute Werte zu erreichen, weil dies zu dem passt, was die Kern-Ranking-Systeme belohnen wollen. Unsere Einschätzung aus der Praxis: Die Core Web Vitals entscheiden selten allein über eine Position, können aber bei inhaltlich vergleichbaren Seiten den Ausschlag geben – und wirken unabhängig vom Ranking direkt auf Absprungrate und Conversion, weil Nutzer langsame und springende Seiten schlicht schlechter bedienen können.

Felddaten und Labordaten: Woher Ihre Werte kommen

Für die Bewertung der Core Web Vitals zählen Felddaten echter Nutzer; Labordaten aus simulierten Tests helfen dabei, die Ursachen zu finden.

Die wichtigste Felddatenquelle ist der Chrome UX Report (CrUX): ein Datensatz, der zeigt, wie echte Chrome-Nutzer beliebte Websites erleben. Damit eine Seite oder Domain aufgenommen wird, muss sie öffentlich auffindbar sein und genügend Besucher für einen statistisch aussagekräftigen Datensatz haben.

Laut der Dokumentation von PageSpeed Insights besteht eine Seite die Core-Web-Vitals-Bewertung, wenn das 75. Perzentil aller drei Messwerte im guten Bereich liegt. Die Felddaten beziehen sich auf die vorangegangenen 28 Tage. Labordaten sind laut Google nützlich für die Fehlersuche, bilden reale Engpässe aber möglicherweise nicht ab. Der Lighthouse-Performance-Score – 90 und mehr gilt als gut – ist deshalb ein Laborwert und nicht dasselbe wie die Core-Web-Vitals-Bewertung.

So lesen Sie den Search-Console-Bericht

Der Core-Web-Vitals-Bericht fasst URLs mit ähnlicher Nutzererfahrung zu Gruppen zusammen. Eine URL-Gruppe erhält dabei immer den schlechtesten Status ihrer Messwerte für den jeweiligen Gerätetyp: Ist der LCP gut, der CLS aber langsam, gilt die ganze Gruppe als langsam. Gruppen ohne ausreichende Daten erscheinen nicht im Bericht. Wenn Sie ein Problem behoben haben, können Sie die Korrektur überprüfen lassen; Google beobachtet die betroffenen URLs dann 28 Tage lang und wertet das Problem nur als behoben, wenn es bei keiner URL der Gruppe mehr auftritt. Wie Sie die Search Console insgesamt sinnvoll nutzen, beschreibt unser Leitfaden zur Google Search Console.

LCP verbessern: den Hauptinhalt schneller zeigen

Ein schlechter LCP lässt sich fast immer einem von vier Teilschritten zuordnen – und erst diese Zuordnung zeigt, welche Maßnahme wirkt.

Als LCP-Element kommen laut web.dev Bilder, Bilder innerhalb von SVG, Poster-Bilder von Videos, per url() geladene Hintergrundbilder und Block-Elemente mit Text in Frage. In der Praxis ist es meist das Hero-Bild oder die erste große Überschrift. Den LCP-Optimierungsleitfaden von web.dev zerlegt die Zeit bis zum LCP in vier Teile und nennt als grobe Orientierung, welchen Anteil sie bei einer gut optimierten Seite haben sollten – ausdrücklich als Richtwerte, nicht als feste Regeln:

1. Time to First Byte (TTFB), etwa 40 Prozent: die Zeit, bis der Browser das erste Byte der HTML-Antwort erhält. Ansatzpunkte sind laut web.dev möglichst wenige Weiterleitungen und ein CDN, dessen Cache tatsächlich greift – etwa ohne individuelle URL-Parameter, die das Caching verhindern.
2. Verzögerung bis zum Laden der LCP-Ressource, unter 10 Prozent: die Wartezeit, bis der Browser das LCP-Bild überhaupt anfordert. Die Ressource sollte direkt im HTML auffindbar sein; ist sie nur über CSS oder JavaScript referenziert, empfiehlt web.dev ein Preload mit hoher Priorität. Das LCP-Bild sollte fetchpriority="high" erhalten und niemals per Lazy Loading geladen werden.
3. Ladedauer der LCP-Ressource, etwa 40 Prozent: die Zeit, die das Bild selbst zum Laden braucht. Hier helfen kleinere Dateien durch passende Bildgrößen, moderne Formate und Komprimierung, ein CDN und eine effiziente Cache-Steuerung.
4. Verzögerung beim Rendern, unter 10 Prozent: die Zeit zwischen geladenem Bild und fertig dargestelltem Element. Ursachen sind vor allem render-blockierendes CSS und synchrone Skripte im Kopfbereich sowie lange Tasks im Haupt-Thread.

INP verbessern: schneller auf Eingaben reagieren

INP misst, wie lange es nach einer Eingabe dauert, bis die Seite sichtbar reagiert – und wird fast immer durch zu viel JavaScript im Haupt-Thread verschlechtert.

Laut web.dev zählen für INP Mausklicks, das Antippen auf Touchscreens und Tastatureingaben; Hovern und Scrollen werden nicht berücksichtigt. Als Wert wird die längste beobachtete Interaktion eines Besuchs verwendet, wobei bei vielen Interaktionen Ausreißer ignoriert werden – je 50 Interaktionen fällt die langsamste heraus. Jede Interaktion besteht aus drei Phasen:

• Eingabeverzögerung: die Zeit, bevor der Browser überhaupt beginnt, die Interaktion zu verarbeiten – etwa weil gerade ein anderes Skript läuft.
• Verarbeitungsdauer: die Zeit, in der die zugehörigen Event-Handler ausgeführt werden.
• Darstellungsverzögerung: die Zeit nach den Handlern, bis der nächste Frame auf dem Bildschirm erscheint.

Der INP-Optimierungsleitfaden empfiehlt, mit Felddaten zu beginnen, um die tatsächlich langsamen Interaktionen zu finden, und sie erst danach im Labor nachzustellen. Die wichtigsten Hebel sind laut web.dev: lange Aufgaben aufteilen und regelmäßig an den Haupt-Thread zurückgeben, sogenanntes Layout Thrashing vermeiden (also nicht abwechselnd Styles ändern und Layoutwerte auslesen) und die Größe des DOM begrenzen, weil ein sehr großes DOM sowohl das erste Rendern als auch spätere Interaktionen verlangsamt.

Aus unserer Praxis ergänzen wir: Prüfen Sie bei schlechtem INP zuerst eingebundene Drittanbieter-Skripte wie Chat-Widgets, Tag-Manager-Container mit vielen Tags oder Consent-Lösungen. Sie laufen im selben Haupt-Thread wie Ihre Seite und sind häufig für die Eingabeverzögerung verantwortlich.

CLS verbessern: das Layout stabil halten

CLS misst unerwartete Layoutverschiebungen, die Besucher beim Lesen stören oder zu Fehlklicks führen, und lässt sich meist mit reserviertem Platz beheben.

Laut web.dev erfasst CLS den größten „Ausbruch“ an Layoutverschiebungen: Verschiebungen werden in Zeitfenstern zusammengefasst, in denen zwischen zwei Verschiebungen weniger als eine Sekunde liegt und die insgesamt höchstens fünf Sekunden dauern. Verschiebungen innerhalb von 500 Millisekunden nach einer Nutzereingabe zählen nicht, weil Nutzer sie erwarten. Die häufigsten Ursachen und Gegenmaßnahmen nennt der CLS-Optimierungsleitfaden:

Typische CLS-Quellen in Unternehmenswebsites sind nach unserer Erfahrung Cookie- oder Aktionsbanner, die den Inhalt nach unten schieben, statt ihn zu überlagern, sowie Bildergalerien und Slider ohne festes Seitenverhältnis.

Ladezeit über die drei Messwerte hinaus: was wirklich zählt

Die Core Web Vitals zeigen, wo eine Seite hakt – die eigentliche Ladezeit entsteht aber schon davor: auf dem Server, auf dem Weg durchs Netz und in den Dateien, die der Browser laden muss.

Der erste Prüfpunkt ist die Time to First Byte. Laut web.dev umfasst sie Weiterleitungen, DNS-Abfrage, Verbindungsaufbau samt TLS und die Anfrage bis zum ersten Byte der Antwort. Die meisten Websites sollten 0,8 Sekunden oder weniger anstreben; web.dev nennt das ausdrücklich einen groben Richtwert und stellt klar, dass TTFB kein Core Web Vital ist. Relevant ist der Wert trotzdem, weil jede Verzögerung hier alle folgenden Schritte – allen voran den LCP – nach hinten schiebt. Die übrigen Hebel betreffen Server, Dateien und eingebundene Dienste:

Aus unserer Praxis: Ein guter Teil dieser Hebel ist Konfiguration statt Entwicklung. CDN, Kompression und Cache-Header lassen sich bei vielen Hostern und Shopsystemen in den Einstellungen aktivieren; ob sie greifen, sehen Sie in den Chrome DevTools im Netzwerk-Tab an den Antwort-Headern. Messen Sie den Erfolg dennoch an den Felddaten: Eine schnellere Server-Antwort, die den LCP Ihrer Besucher nicht verbessert, bringt ihnen wenig.

Priorisieren: wo Sie zuerst ansetzen

Die wirksamste Reihenfolge ergibt sich aus Ihren Felddaten, nicht aus einer allgemeinen Checkliste.

Wir gehen in Projekten in fünf Schritten vor – eine Praxisempfehlung, keine Vorgabe von Google:

1. Problem eingrenzen: Im Search-Console-Bericht ablesen, welcher Messwert auf welchem Gerätetyp und in welcher URL-Gruppe schlecht ist.
2. Vorlagen statt Einzel-URLs denken: URL-Gruppen entsprechen meist Seitenvorlagen wie Produkt-, Kategorie- oder Blogseiten. Eine Korrektur an der Vorlage verbessert alle Seiten der Gruppe zugleich.
3. Nach Reichweite ordnen: Vorlagen mit den meisten Besuchen und dem größten Umsatzbeitrag zuerst bearbeiten.
4. Ursache im Labor finden: Repräsentative URLs mit PageSpeed Insights und den Chrome DevTools analysieren und die Maßnahme dem betroffenen Teilschritt zuordnen.
5. Wirkung im Feld prüfen: Nach dem Deployment die Korrektur in der Search Console überprüfen lassen und die 28-tägige Beobachtung abwarten.

Viele Performance-Probleme entstehen bereits bei der Wahl von Theme, Baukasten und Plugins. Wer eine neue Website plant, sollte Leistungsziele deshalb von Anfang an ins Lastenheft schreiben – das gehört bei unseren Website- und Webshop-Projekten zum Standard. Was von AMP als früherer Abkürzung zu schnellen Mobilseiten bleibt, lesen Sie im Beitrag Was ist AMP?.

Häufige Fragen

Was sind die Core Web Vitals?

Die Core Web Vitals sind drei Messwerte, mit denen Google die Nutzererfahrung einer Seite beschreibt: Largest Contentful Paint (LCP) für die Ladeleistung, Interaction to Next Paint (INP) für die Reaktionsfähigkeit und Cumulative Layout Shift (CLS) für die visuelle Stabilität. Sie gelten laut web.dev für alle Webseiten.

Welche Werte gelten als gut?

Als gut gelten ein LCP von höchstens 2,5 Sekunden, ein INP von höchstens 200 Millisekunden und ein CLS von höchstens 0,1. Maßgeblich ist das 75. Perzentil der Seitenaufrufe, getrennt für Mobilgeräte und Desktop.

Sind die Core Web Vitals ein Rankingfaktor?

Google schreibt, dass die Core Web Vitals von den Ranking-Systemen verwendet werden. Gleichzeitig betont Google, dass die Suche immer die relevantesten Inhalte zeigen will, auch wenn die Seitenerfahrung nicht optimal ist, und dass gute Werte kein Top-Ranking garantieren. Relevanz und Qualität des Inhalts bleiben also vorrangig.

Was hat INP mit FID zu tun?

Interaction to Next Paint hat 2024 First Input Delay als Core-Web-Vital-Messwert abgelöst. Anders als FID betrachtet INP nicht nur die erste Interaktion, sondern die Reaktionszeit über alle Klicks, Tipps und Tastatureingaben während eines Besuchs.

Warum unterscheiden sich PageSpeed Insights und Lighthouse-Werte von der Search Console?

Die Search Console und der Felddaten-Bereich von PageSpeed Insights zeigen Messwerte echter Chrome-Nutzer aus dem Chrome UX Report. Lighthouse misst dagegen im Labor unter simulierten Bedingungen. Labordaten eignen sich zur Fehlersuche, bilden aber laut Google nicht unbedingt reale Engpässe ab.

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

Die Felddaten beruhen auf einem Zeitraum von 28 Tagen. Wenn Sie im Core-Web-Vitals-Bericht eine Korrektur überprüfen lassen, beobachtet Google die betroffenen URLs ebenfalls 28 Tage lang. Mit spürbaren Änderungen im Bericht sollten Sie deshalb erst nach einigen Wochen rechnen.

Gehört die Server-Antwortzeit (TTFB) zu den Core Web Vitals?

Nein. Laut web.dev ist die Time to First Byte kein Core-Web-Vitals-Messwert. Als grober Richtwert sollten die meisten Websites eine TTFB von höchstens 0,8 Sekunden anstreben. Wichtig ist sie trotzdem, weil eine langsame Server-Antwort alle folgenden Ladeschritte verzögert, vor allem den Largest Contentful Paint.

Fazit: Für Menschen messen, nicht für die Punktzahl

Die Core Web Vitals übersetzen Nutzererfahrung in drei überprüfbare Zahlen: Wie schnell erscheint der Hauptinhalt, wie zügig reagiert die Seite, wie ruhig bleibt das Layout. Google nutzt sie im Ranking, stellt aber Relevanz und Qualität darüber. Wer seine Felddaten liest, Probleme den richtigen Teilschritten zuordnet und Vorlagen statt Einzelseiten verbessert, erreicht mit überschaubarem Aufwand gute Werte – und macht die Website vor allem für die Menschen besser, die sie besuchen.

• Zielwerte: LCP bis 2,5 s, INP bis 200 ms, CLS bis 0,1 – jeweils am 75. Perzentil.
• Datenbasis: Felddaten aus Search Console und PageSpeed Insights bewerten, Labordaten zur Ursachensuche nutzen.
• LCP: Hero-Bild früh auffindbar, priorisiert, nicht lazy geladen, klein genug.
• Ladezeit: TTFB, CDN, Caching, Kompression, Bildformate und Drittanbieter-Skripte prüfen.
• INP: lange Tasks aufteilen, Drittanbieter-Skripte prüfen, DOM schlank halten.
• CLS: Platz für Bilder, Anzeigen, Embeds und Schriften reservieren.