Core Web Vitals einfach erklärt: LCP, INP, CLS

Was sind Core Web Vitals?

Core Web Vitals sind eine kleine Auswahl von Metriken aus Googles größerem Web-Vitals-Programm, mit denen Google die Qualität der Nutzererfahrung einer Website messbar macht. Sie beantworten drei einfache Fragen aus Sicht deiner Besucher: Lädt die Seite schnell? Reagiert sie zügig auf meine Klicks? Bleibt das Layout ruhig, während sie lädt? Diese drei Aspekte heißen Ladeleistung, Interaktivität und visuelle Stabilität.

Das Besondere daran ist, dass die Werte nicht in einem Labor entstehen, sondern aus dem echten Verhalten von Chrome-Nutzern auf deiner Seite. Google sammelt diese anonymisierten Daten im Chrome User Experience Report (CrUX) und nutzt sie, um zu beurteilen, wie sich deine Seite tatsächlich anfühlt. Damit sind Core Web Vitals kein reines Entwickler-Thema, sondern eine direkte Messung dessen, was Besucher erleben.

Die drei Metriken: LCP, INP und CLS

Jede der drei Metriken deckt einen anderen Teil der Nutzererfahrung ab und hat einen klar definierten Schwellenwert für „gut". Wichtig ist: Google bewertet immer das 75. Perzentil deiner Seitenaufrufe. Das heißt, mindestens 75 Prozent der Besuche müssen im grünen Bereich liegen, damit die Seite besteht. Ein einzelner guter Testlauf reicht nicht.

LCP: Largest Contentful Paint

LCP misst die Ladeleistung: die Zeit, bis das größte sichtbare Element im Viewport vollständig erscheint. Meist ist das ein Hero-Bild, ein großer Textblock oder ein Video. Der Wert sagt dir, wann der Besucher das Gefühl hat, dass die Seite fertig geladen ist. Gut ist ein LCP unter 2,5 Sekunden, verbesserungswürdig bis 4 Sekunden, alles darüber gilt als schlecht.

Typische Ursachen für einen schlechten LCP sind langsame Serverantwortzeiten (eine hohe Time to First Byte), große unkomprimierte Bilder und Render-blockierendes JavaScript oder CSS. Ein häufiger Fehler: das Hero-Bild per Lazy Loading zu verzögern. Genau das LCP-Element sollte sofort laden, nicht später.

INP: Interaction to Next Paint

INP misst die Interaktivität: wie schnell die Seite auf Interaktionen des Nutzers reagiert. Klickst du auf einen Button, tippst du oder öffnest ein Menü, dann misst INP die Zeit, bis die Seite sichtbar antwortet. Anders als der Vorgänger schaut INP nicht nur auf die erste Interaktion, sondern auf alle Interaktionen während des Besuchs und meldet die längste. Gut ist ein INP unter 200 Millisekunden, verbesserungswürdig bis 500 Millisekunden, darüber schlecht.

Wichtig für 2026: INP hat First Input Delay (FID) am 12. März 2024 offiziell als Core Web Vital abgelöst. Wenn du irgendwo noch FID liest, ist die Quelle veraltet. Die häufigste Ursache für schlechten INP ist schweres JavaScript, das den Haupt-Thread blockiert, dazu zu viele Event-Listener und Third-Party-Skripte wie Chat-Widgets, Analytics oder Ads.

CLS: Cumulative Layout Shift

CLS misst die visuelle Stabilität: wie stark sich sichtbare Elemente während des Ladens unerwartet verschieben. Jeder kennt den Moment, in dem man auf einen Button tippen will und er im letzten Augenblick wegspringt, weil ein Bild oder ein Banner nachgeladen wurde. CLS fasst all diese Verschiebungen zu einem Wert zusammen. Gut ist ein CLS unter 0,1, verbesserungswürdig bis 0,25, darüber schlecht. CLS hat keine Einheit, weil es ein Verhältnis aus Verschiebungsgröße und Sichtbereich ist.

Typische Ursachen sind Bilder ohne feste Breiten- und Höhenangaben, dynamisch nachgeladene Werbebanner, Web-Fonts, die den Text nachträglich umbrechen, und Einbettungen ohne reservierten Platz. Die Lösung ist fast immer, den Platz vorab zu reservieren, etwa über feste Dimensionen oder das CSS-Attribut aspect-ratio.

Wie misst du deine Core Web Vitals?

Beim Messen gibt es einen Unterschied, der über alles entscheidet: Labordaten gegen Felddaten. Wer das verwechselt, optimiert oft an der falschen Stelle. Für das Google-Ranking zählen ausschließlich die Felddaten.

Felddaten gegen Labordaten

Labordaten (Lab Data) entstehen in einer kontrollierten, simulierten Umgebung, zum Beispiel mit Google Lighthouse. Sie sind ideal zum Debuggen und für wiederholbare Tests während der Entwicklung, weil sie stabil und reproduzierbar sind. Aber sie spiegeln nicht wider, was echte Nutzer auf echten Geräten erleben. Ein Hinweis: INP lässt sich im Labor gar nicht direkt messen, weil dort niemand interagiert. Lighthouse nutzt stattdessen die Total Blocking Time (TBT) als Näherungswert.

Felddaten (Field Data) sind die Werte echter Chrome-Nutzer, gesammelt im Chrome User Experience Report. Genau diese Daten nutzt Google für das Ranking und zeigt sie im Core-Web-Vitals-Bericht der Search Console. Der klassische Fehler: eine grüne Lighthouse-Zahl von 95 feiern, während die Felddaten rot sind. Was zählt, ist das Feld.

Die richtigen Tools

Für den Einstieg reichen ein paar kostenlose Google-Tools, die alle drei Metriken abdecken. PageSpeed Insights (pagespeed.web.dev) ist der beste Startpunkt: Es zeigt sowohl Feld- als auch Labordaten für Mobil und Desktop getrennt und gibt konkrete Empfehlungen. Der Core-Web-Vitals-Bericht in der Google Search Console gibt dir den Überblick über alle URLs deiner Seite, gruppiert nach Status und Seitentyp, und zeigt Trends über die Zeit. Für die Detailanalyse einzelner Seiten nutzt du die Chrome DevTools mit dem Lighthouse- und dem Performance-Tab. Wer eigene Live-Überwachung will, misst mit der web-vitals-JavaScript-Bibliothek direkt im eigenen Code.

Wie verbesserst du jede Metrik?

Die Optimierung folgt der Diagnose. Statt blind Plugins zu installieren, gehst du pro Metrik gezielt an die Ursachen. Hier die wirksamsten Hebel, sortiert nach den drei Werten.

LCP verbessern

LCP ist meist am einfachsten zu verbessern, weil die Ursachen klar sind: große Dateien und langsame Antwortzeiten. Optimiere zuerst deine Bilder mit modernen Formaten wie WebP oder AVIF, die 30 bis 50 Prozent kleiner sind als JPEG oder PNG, und lade das Hero-Bild bewusst nicht per Lazy Loading. Senke die Serverantwortzeit über gutes Hosting, Caching und ein CDN, das Inhalte vom nächstgelegenen Server ausliefert. Und eliminiere Render-blockierende Ressourcen, indem du kritisches CSS inline setzt und JavaScript mit defer oder async lädst.

INP verbessern

INP ist technisch anspruchsvoller, weil es am JavaScript hängt. Der wirksamste Hebel ist, weniger und schlankeres JavaScript auszuliefern: Code-Splitting, damit nur geladen wird, was die Seite wirklich braucht, und das Aufbrechen langer Tasks, die den Haupt-Thread über 50 Millisekunden blockieren. Reduziere Third-Party-Skripte auf das Nötige, denn jedes Tracking-Pixel und jedes Chat-Widget kostet Reaktionszeit. Bei aufwendigen Berechnungen helfen Web Worker, die Arbeit in einen separaten Thread auslagern, sowie Debouncing und Throttling bei Scroll- oder Resize-Events.

CLS verbessern

CLS ist oft am schnellsten zu beheben, wenn man weiß, wo die Sprünge entstehen. Gib Bildern und Videos immer feste Breiten- und Höhenangaben oder nutze aspect-ratio in CSS, damit der Browser den Platz reserviert, bevor das Element geladen ist. Reserviere feste Container für dynamische Inhalte wie Werbebanner und Einbettungen. Lade Web-Fonts sauber mit font-display: swap und preload, damit der Text nicht nachträglich umbricht. Und animiere über transform statt über top oder left, weil CSS-Transforms keine Layout-Verschiebungen auslösen.

Fehlerbehebung validieren

Wenn du ein Problem behoben hast, bestätige das nicht mit einem einzelnen Labortest, sondern in der Search Console. Dort startest du über „Fehlerbehebung überprüfen" einen 28-tägigen Überwachungszeitraum. Google prüft dabei, ob die Verbesserung bei den echten Nutzern in den Felddaten wirklich angekommen ist. Weil CrUX auf einem rollierenden 28-Tage-Fenster basiert, brauchen Änderungen entsprechend Zeit, bis sie sich vollständig in den Werten zeigen. Geduld gehört hier zum Prozess.

Wie wichtig sind Core Web Vitals fürs Ranking wirklich?

Ehrliche Einordnung: Core Web Vitals sind seit Juni 2021 ein bestätigter Google-Ranking-Faktor, Teil der sogenannten Page-Experience-Signale. Aber sie sind einer von hunderten Faktoren. Relevanter, guter Inhalt schlägt Performance fast immer. Eine schnelle Seite ohne passenden Inhalt rankt nicht, nur weil sie schnell ist.

In der Praxis wirken Core Web Vitals als Tie-Breaker: Wenn zwei Seiten inhaltlich und in ihrer Autorität gleichauf liegen, gewinnt die technisch bessere. In der Google Search Console fasst Google außerdem URLs mit ähnlicher Struktur zu Gruppen zusammen, sodass ein Template-Problem den Status hunderter Seiten gleichzeitig kippen kann. Aktuell (CrUX-Auswertung Mai 2026) bestehen rund 55,9 Prozent aller erfassten Websites alle drei Core Web Vitals gleichzeitig, mit 68,6 Prozent gutem LCP, 86,6 Prozent gutem INP und 81,3 Prozent gutem CLS. Es gibt also weiterhin Vorsprung zu holen.

Der stärkere Grund ist ohnehin nicht das Ranking, sondern das Geschäft. Schnelle, stabile Seiten halten Besucher und konvertieren besser. Als Vodafone Italien den LCP um 31 Prozent verbesserte, stiegen die Verkäufe um 8 Prozent und die Leads um 15 Prozent. Performance ist damit weniger ein SEO-Trick als ein direkter Umsatz-Hebel, was sauber zur Conversion-Optimierung passt.

Warum wir Performance von Anfang an mitbauen

Hier liegt der Punkt, den viele Ratgeber überspringen: Die meisten Core-Web-Vitals-Probleme sind hausgemacht und stammen aus der Bauweise der Website. Ein überladenes WordPress-Theme mit Page-Builder-Ballast, fünf sich überlappende Plugins und ein billiges Shared-Hosting sind schwer nachträglich zu retten. Man optimiert dann monatelang gegen die eigene Architektur an.

Wir gehen den umgekehrten Weg. Auf Webflow und Next.js bauen wir Performance von Anfang an in die Struktur ein: serverseitiges Rendering, schlankes JavaScript, optimierte Bilder und feste Layout-Dimensionen sind bei uns Standard, nicht Nachtrag. Bei Next.js kommen automatische Bildoptimierung, Code-Splitting und moderne Rendering-Strategien dazu, die LCP und INP direkt zugutekommen. Das Ergebnis sind Seiten, die die grünen Schwellenwerte nicht mit Ach und Krach erreichen, sondern mit Puffer, weil das Fundament stimmt. Genau darum ist eine schnelle Seite bei uns kein Extra-Projekt, sondern Teil der Bauweise, und ein wichtiger Grund, warum ein Relaunch ohne SEO-Verlust auch technisch sauber gelingt.

Häufige Fragen