Core Web Vitals: LCP, INP und CLS messen und verbessern

Eine Seite kann schnell wirken und trotzdem nerven: Das große Bild erscheint spät, ein Klick auf das Menü bleibt eine Sekunde ohne Antwort, oder der Text springt nach unten, weil darüber eine Anzeige nachlädt. Genau diese drei Erfahrungen messen die Core Web Vitals. Hier liest du, was hinter LCP, INP und CLS steckt, welche Werte als gut gelten, wie viel Gewicht Google ihnen gibt und was du an der eigenen Website ändern kannst.

Was die Core Web Vitals messen

Google beschreibt die Core Web Vitals als Messwerte zur Nutzerfreundlichkeit in Bezug auf Ladezeit, Interaktivität und visuelle Stabilität ^[1]. Dazu gehören drei Werte ^{[1, 2]}:

• Largest Contentful Paint (LCP) misst die Ladeleistung. Erfasst wird, wann das größte sichtbare Bild, der größte Textblock oder das größte Video im sichtbaren Bereich gerendert ist ^[3].
• Interaction to Next Paint (INP) misst die Reaktionsschnelligkeit. Gezählt werden Klicks, Tipps auf dem Touchscreen und Tastatureingaben während des ganzen Besuchs; Scrollen, Zoomen und Darüberfahren mit der Maus zählen nicht ^[4].
• Cumulative Layout Shift (CLS) misst die visuelle Stabilität, also wie stark sich Elemente unerwartet verschieben. Gewertet wird der größte Schub solcher Verschiebungen ^[5].

Die Search Console ordnet jeden Wert in drei Stufen ein ^[6]:

Maßgeblich ist das 75. Perzentil aller Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Eine Seite besteht, wenn sie bei allen drei Werten im 75. Perzentil im grünen Bereich liegt ^[2]. INP hat am 12.03.2024 den früheren Messwert First Input Delay (FID) als Core Web Vital abgelöst ^[7].

Dass sich die Liste ändert, ist vorgesehen. web.dev beschreibt einen Lebenszyklus mit den Stufen experimentell, ausstehend und stabil. Ein Messwert bleibt mindestens sechs Monate in der Stufe ausstehend, stabile Werte werden höchstens einmal im Jahr geändert und sind trotzdem nicht auf Dauer garantiert ^[2]. LCP, CLS und INP gelten derzeit als stabil ^[2]. INP wurde 2023 vom experimentellen in den ausstehenden Status befördert und 2024 stabil ^[2].

Welche Rolle sie im Ranking spielen

Google schreibt: "Core Web Vitals werden von unseren Rankingsystemen genutzt." ^[8] Google empfiehlt Websitebetreibern, gute Werte anzustreben ^[8]. Gleichzeitig schränkt Google ein: Gute Ergebnisse in den Berichten können nicht garantieren, dass Seiten ganz oben in den Suchergebnissen erscheinen ^[8]. Die Suche versucht nach eigener Aussage immer, die relevantesten Inhalte anzuzeigen, und ein einzelnes Signal für die Nutzerfreundlichkeit gibt es nicht; die Rankingsysteme berücksichtigen mehrere solcher Signale ^[8].

Gute Werte ersetzen also keinen Inhalt, der zur Suchanfrage passt. Ladezeit und Stabilität betreffen aber jeden Besucher, auch die, die über Links oder direkt kommen. Wie Google Seiten insgesamt bewertet, erklärt So entscheidet Google über das Ranking.

Felddaten und Labordaten

Es gibt zwei Arten, die Werte zu erheben. Felddaten stammen von echten Besuchern, etwa aus dem Chrome User Experience Report (CrUX). Sie zeigen die tatsächliche Erfahrung, eignen sich aber nicht, um einen einzelnen Seitenaufruf zu untersuchen ^[2]. Labordaten entstehen in einer simulierten Umgebung ohne Nutzer. Sie helfen bei der Entwicklung und beim Erkennen von Verschlechterungen, ersetzen die Messung im Feld aber nicht ^[2]. INP lässt sich im Labor nicht messen, weil dort niemand klickt; web.dev nennt die Total Blocking Time (TBT) als Ersatzgröße ^[2].

Felddaten liefern unter anderem PageSpeed Insights und der Core-Web-Vitals-Bericht der Search Console, Labordaten etwa Lighthouse in den Chrome-Entwicklertools. Lighthouse misst LCP und CLS, aber nicht INP ^[2]. Der Bericht in der Search Console fasst ähnliche Seiten zu URL-Gruppen zusammen; der Status einer Gruppe richtet sich nach ihrem schlechtesten Messwert ^[6]. Hat eine Gruppe zu wenige Daten, erscheint sie nicht. Nach einer Korrektur kannst du über "Tracking starten" die Überprüfung beginnen; die Search Console beobachtet das Problem dann 28 Tage lang ^[6]. Die Einrichtung beschreibt Google Search Console einrichten und nutzen. Ein Messwerkzeug für Labordaten ist PageSpeed.de, das von SEO NW stammt, dem Betreiber dieser Website; mehr dazu unter PageSpeed.de: Ladezeit messen.

LCP verbessern

Als LCP-Element kommen Bilder (auch Bilder in SVG), Videos, Elemente mit einem per CSS geladenen Hintergrundbild und Blockelemente mit Text infrage ^[3]. web.dev zerlegt die Zeit bis zum LCP in vier Teile: die Zeit bis zum ersten Byte (TTFB), die Verzögerung, bis das Laden der Ressource beginnt, die Ladedauer der Ressource und die Verzögerung beim Rendern des Elements ^[9]. Für jeden Teil gibt es eigene Maßnahmen ^[9]:

• Das wahrscheinliche LCP-Bild bekommt das Attribut fetchpriority="high". Steckt es nur in einer CSS- oder JavaScript-Datei, wird es mit hoher Priorität vorab geladen (preload).
• Das LCP-Bild wird nie verzögert geladen (lazy loading); laut web.dev führt das immer zu einer unnötigen Verzögerung.
• Eine lange Zeit bis zum ersten Byte kann einen LCP von 2,5 Sekunden schwer oder unmöglich machen. Ein Content Delivery Network verkürzt den Weg der Daten.
• Bilder werden komprimiert und in modernen Formaten ausgeliefert.
• Stylesheets, die das Rendern blockieren, werden verkleinert oder bei geringer Größe direkt in die Seite geschrieben.

Was ein CDN konkret an Ladezeit bringt und wo seine Grenzen liegen, erklärt domain-root.de unter Was ein CDN für Ladezeit und Core Web Vitals bringt. WordPress setzt seit Version 6.3 das Attribut fetchpriority="high" automatisch für das Bild, das am wahrscheinlichsten das LCP-Element ist. Die Erkennung von Bildern im sichtbaren Bereich, die nicht verzögert geladen werden sollen, hat WordPress seit Version 5.9 schrittweise verbessert ^[12]. Zu Dateiformaten und Bildgrößen gibt es den Ratgeber Bilder für die Suche optimieren.

INP verbessern

Eine Interaktion besteht aus drei Phasen: der Eingabeverzögerung ab dem Klick, der Verarbeitungsdauer der Event-Handler und der Darstellungsverzögerung, bis der Browser das nächste Bild zeichnet ^[10]. Als Wert für die Seite meldet INP die längste beobachtete Interaktion, wobei Ausreißer unberücksichtigt bleiben: Bei vielen Interaktionen fällt je 50 Interaktionen die längste heraus ^[4].

web.dev nennt diese Ansatzpunkte ^[10]:

• Arbeit in Event-Handlern auf mehrere Aufgaben verteilen, etwa mit setTimeout, damit der Browser dazwischen reagieren kann.
• Layout-Thrashing vermeiden, also das wiederholte Lesen und Schreiben von Layoutwerten, das den Browser zu erzwungenen Neuberechnungen zwingt.
• Das DOM klein halten, denn bei wenigen Elementen ist die Arbeit für das Rendern meist schnell erledigt.

In der Praxis sind oft Skripte von Drittanbietern beteiligt, etwa für Chat-Fenster, Tracking oder eingebettete Inhalte. Wer jedes Skript daraufhin prüft, ob es noch gebraucht wird, findet meist schnell die ersten Kandidaten.

CLS verbessern

Typische Ursachen für Verschiebungen sind Bilder oder Videos ohne bekannte Abmessungen, Schriften, die größer oder kleiner rendern als die Ersatzschrift, Anzeigen oder Widgets, die ihre Größe selbst ändern, und Elemente, die nachträglich über bestehendem Inhalt eingefügt werden ^[5]. Verschiebungen innerhalb von 500 Millisekunden nach einer Eingabe des Nutzers werden gekennzeichnet und können aus der Berechnung herausfallen, weil der Nutzer sie erwartet ^[5]. Gemessen wird in Zeitfenstern: Ein Schub umfasst Verschiebungen mit weniger als einer Sekunde Abstand und dauert höchstens fünf Sekunden. Der CLS-Wert ist der Schub mit der höchsten Summe ^[5]. Eine Seite, die lange geöffnet bleibt, sammelt deshalb nicht endlos Punkte an.

Dagegen hilft laut web.dev ^[11]:

• Bilder und Videos immer mit den Attributen width und height versehen oder den Platz per CSS mit aspect-ratio reservieren.
• Für Anzeigen, Einbettungen und spät geladene Inhalte von Anfang an Platz im Layout freihalten; geht das nicht, solche Inhalte weiter unten platzieren.
• Wichtige Webschriften früh mit <link rel=preload> laden, font-display: optional nutzen und Größenunterschiede zur Ersatzschrift mit size-adjust und verwandten Angaben ausgleichen.
• Animationen mit transform umsetzen statt mit Eigenschaften, die das Layout neu berechnen.
• Die Seite für den Back/Forward-Cache geeignet halten, damit sie beim Zurückgehen ohne erneute Verschiebungen wiederhergestellt wird.

In welcher Reihenfolge du vorgehst

Ein sinnvoller Einstieg ist der Core-Web-Vitals-Bericht der Search Console, weil er auf echten Nutzerdaten beruht und ähnliche Seiten gruppiert. So siehst du, ob ein Problem eine ganze Vorlage betrifft, etwa alle Produktseiten, oder nur einzelne Adressen. Danach prüfst du eine typische Seite der Gruppe mit einem Labortest, um die Ursache zu finden. Korrekturen an einer Vorlage wirken auf alle Seiten der Gruppe auf einmal. Nach der Änderung startest du die Validierung und wartest die 28 Tage ab ^[6].

Weitere Themen des technischen SEO, von der robots.txt bis zu strukturierten Daten, findest du im Bereich Technisches SEO. Für WordPress gibt es eigene Stellschrauben, siehe SEO für WordPress.

1. Organisation Core Web Vitals und Google-Suchergebnisse. Google Search Central. Stand 18.12.2025. abgerufen am 29.10.2026
2. Organisation Web Vitals. web.dev, Google. Stand 31.10.2024. abgerufen am 29.10.2026
3. Organisation Largest Contentful Paint (LCP). web.dev, Google. Stand 04.09.2025. abgerufen am 29.10.2026
4. Organisation Interaction to Next Paint (INP). web.dev, Google. Stand 02.09.2025. abgerufen am 29.10.2026
5. Organisation Cumulative Layout Shift (CLS). web.dev, Google. Stand 12.04.2023. abgerufen am 29.10.2026
6. Organisation Core Web Vitals-Bericht. Search Console-Hilfe, Google. Stand ohne Datum. abgerufen am 29.10.2026
7. Organisation Interaction to Next Paint becomes a Core Web Vital on March 12 (Jeremy Wagner, Rick Viscomi). web.dev Blog, Google. Stand 31.01.2024. abgerufen am 29.10.2026
8. Organisation Nutzerfreundlichkeit von Seiten in den Google-Suchergebnissen. Google Search Central. Stand 24.09.2026. abgerufen am 29.10.2026
9. Organisation Largest Contentful Paint optimieren. web.dev, Google. Stand 31.03.2025. abgerufen am 29.10.2026
10. Organisation Interaction to Next Paint optimieren. web.dev, Google. Stand 02.09.2025. abgerufen am 29.10.2026
11. Organisation Cumulative Layout Shift optimieren. web.dev, Google. Stand 07.02.2025. abgerufen am 29.10.2026
12. Organisation Image performance enhancements in WordPress 6.3 (Felix Arntz). Make WordPress Core. Stand 13.07.2023. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.