Core Web Vitals 2026: LCP, INP und CLS (SEO-Leitfaden)

Q: Beeinflussen Core Web Vitals wirklich das Ranking?

Das ist die entscheidende Frage, und die ehrliche Antwort hat zwei Teile. So lässt sich das in eine realistische Strategie übersetzen:

In einem A/B-Test von Vodafone Italia mit zwei visuell und funktional identischen Seiten genügte eine LCP-Verbesserung von 31 %, um 8 % mehr Umsatz zu erzielen – so das offizielle Fallstudie von web.dev. Das ist kein technisches Detail für Ihr Entwicklungsteam: Es ist eine direkte Umsatzvariable. Die Core Web Vitals messen präzise jene Erfahrung, die in den ersten Sekunden darüber entscheidet, ob ein Besucher kauft, Kontakt aufnimmt oder zur Konkurrenz wechselt.

Wenn Sie die Website eines B2B-Unternehmens verwalten, betrifft Sie das genauso wie ein E-Commerce-Betreiber. Ein Kontaktformular, das langsam reagiert, ein Hero-Bereich, der beim Laden springt, oder eine träge Seite auf dem Smartphone sind stille Conversion-Lecks. In diesem Leitfaden erfahren Sie, was Core Web Vitals genau sind, welche Schwellenwerte Google 2026 fordert, wie Sie diese mit zuverlässigen Daten messen und wie Sie jede Metrik Schritt für Schritt optimieren.

Was sind Core Web Vitals und warum sind sie für SEO 2026 relevant?

Core Web Vitals sind eine Teilmenge der Seitenerfahrungs-Metriken, die Google als wesentlich für die Bewertung der tatsächlichen Nutzererfahrung auf jeder Website erachtet. Sie messen nicht, ob eine Seite „schön aussieht", sondern drei messbare Dimensionen ihres Verhaltens: wie schnell der Hauptinhalt angezeigt wird, wie die Seite auf Benutzerinteraktionen reagiert und wie stabil das Layout während des Ladens bleibt.

Im Jahr 2026 umfassen sie drei Metriken:

LCP (Largest Contentful Paint) — Ladegeschwindigkeit des größten sichtbaren Elements.
INP (Interaction to Next Paint) — Reaktionsfähigkeit auf Benutzerinteraktionen.
CLS (Cumulative Layout Shift) — Visuelle Stabilität des Layouts.

Sie sind für SEO relevant, weil sie Teil der Seitenerfahrungs-Signale sind, die Google bewertet. Für das Geschäft sind sie jedoch noch wichtiger. Google hat Ergebnisse wie die von iCook dokumentiert, das seinen Werbeumsatz um 10 % steigerte, nachdem der CLS um 15 % verbessert wurde; Tokopedia erzielte eine um 23 % längere durchschnittliche Sitzungsdauer, nachdem der LCP um 55 % reduziert wurde; Nykaa verzeichnete 28 % mehr organischen Traffic nach einer LCP-Verbesserung von 40 %. Dies sind Zahlen aus dem offiziellen Fallstudien-Repository von web.dev – keine Agenturchätzungen.

Die praktische Schlussfolgerung: Core Web Vitals zu optimieren ist keine „technische Klempnerarbeit", die nur Google gefällt. Es ist ein Hebel für Conversion, Kundenbindung und letztendlich für die kommerzielle Pipeline.

LCP, INP und CLS: von Google empfohlene Schwellenwerte

Google verwendet keine kontinuierliche Skala, sondern klassifiziert jede Metrik in drei Kategorien – „Gut", „Verbesserungswürdig" und „Schlecht" – anhand fester Schwellenwerte. Um zu bestehen, ist stets die Kategorie „Gut" das Ziel. Dies sind die offiziellen Werte gemäß der web.dev-Dokumentation zur Definition der Core-Web-Vitals-Schwellenwerte:

Metrik	Was wird gemessen	Gut	Verbesserungswürdig	Schlecht
LCP	Ladegeschwindigkeit des Hauptinhalts	<= 2,5 s	2,5 s – 4,0 s	> 4,0 s
INP	Reaktionsfähigkeit auf Interaktionen	<= 200 ms	200 ms – 500 ms	> 500 ms
CLS	Visuelle Stabilität (Layoutverschiebung)	<= 0,1	0,1 – 0,25	> 0,25

Es gibt eine Nuance, die die Interpretation Ihrer Berichte grundlegend verändert: Google bewertet diese Schwellenwerte beim 75. Perzentil der realen Besuche. Das bedeutet: Damit eine URL eine Metrik besteht, müssen mindestens 75 % der Seitenaufrufe den „Guten" Schwellenwert erreichen. Es reicht also nicht, dass die Seite auf Ihrem leistungsstarken Laptop mit Glasfaseranschluss schnell ist – sie muss es auch für den viertlangsamsten Nutzer von vier sein, in der Regel jemand mit einem einfachen Smartphone und unbeständiger Mobilverbindung.

Daher kann sich eine Seite schnell anfühlen, wenn Sie sie selbst testen, und dennoch bei den Core Web Vitals scheitern. Das 75. Perzentil zwingt dazu, für das vernünftigste Worst-Case-Szenario zu gestalten, nicht für das Beste.

Warum INP im März 2024 FID abgelöst hat

Jahrelang war die Reaktionsmetrik FID (First Input Delay), der nur die Verzögerung der ersten Benutzerinteraktion maß und zudem nur die Verzögerung bis zur Beginn der Verarbeitung durch den Browser. Es war eine großzügige Metrik: Die meisten Websites bestanden sie mühelos, was sie wenig geeignet machte, wirklich flüssige Erfahrungen von weniger flüssigen zu unterscheiden.

INP (Interaction to Next Paint) löste FID am 12. März 2024 offiziell als Core Web Vital für Reaktionsfähigkeit ab, nachdem dies am 31. Januar desselben Jahres im web.dev-Blog angekündigt worden war. Der Unterschied ist erheblich:

FID maß nur die erste Interaktion; INP beobachtet alle Interaktionen der Sitzung und meldet (annäherungsweise) die schlechteste.
FID maß nur die Eingabeverzögerung; INP misst den vollständigen Zyklus, bis der nächste Frame (Next Paint) die Antwort visuell widerspiegelt.

In der Praxis ist INP deutlich anspruchsvoller und deutlich repräsentativer dafür, wie der Nutzer die Reaktionsschnelligkeit Ihrer Website wahrnimmt. Eine Seite, die Menüs träge öffnete, Formulare mit Verzögerung validierte oder langsam auf Klicks reagierte – für FID unsichtbare Probleme – wird nun offengelegt. Für B2B-Websites mit langen Formularen, Produktfiltern oder Konfiguratoren war diese Änderung besonders relevant.

Wie Sie Ihre Core Web Vitals messen: PageSpeed Insights, CrUX und Search Console

Hier liegt der häufigste und kostspieligste Fehler: Labordaten mit Felddaten zu verwechseln. Sie sind nicht dasselbe, und nur eine davon zählt für das Ranking.

Felddaten vs. Labordaten

Felddaten (field data): Messungen realer Nutzer, die Ihre Website besuchen, gesammelt über den Chrome User Experience Report (CrUX). Es handelt sich um einen gleitenden 28-Tage-Durchschnitt.
Labordaten (lab data): Eine kontrollierte Simulation in einer festen Umgebung, generiert von Lighthouse.

Gemäß der web.dev-Dokumentation darüber, warum Labor- und Felddaten abweichen, verwendet Google für das Ranking ausschließlich die CrUX-Felddaten, nicht die Lighthouse-Labordaten. Letztere dienen der Diagnose: Sie zeigen, warum etwas nicht stimmt, sind aber nicht die Note, die zählt. Deshalb ist es möglich, bei Lighthouse 100 Punkte zu erzielen und dennoch bei den Core Web Vitals in CrUX zu scheitern, wenn Ihre echten Nutzer eine schlechtere Erfahrung machen als die simulierte Umgebung.

Welches Tool wofür verwenden

Tool	Datentyp	Granularität	Bester Einsatz
PageSpeed Insights	Feld (CrUX) + Labor (Lighthouse)	Einzelne URL; CrUX täglich aktualisiert	Diagnose einer konkreten Seite
Google Search Console	Nur Feld (CrUX)	Aggregiert nach URL-Gruppen	Übersicht über Website-Gesundheit und problematische URLs
Lighthouse / DevTools	Nur Labor	Einzelne URL, punktuelle Ausführung	Korrekturen debuggen und vor dem Deployment testen

Gemäß der Google for Developers-Dokumentation zu PageSpeed Insights zeigt das Tool sowohl CrUX-Felddaten (täglich auf URL-Ebene aktualisiert) als auch Lighthouse-Labordaten. Google Search Console hingegen meldet ausschließlich CrUX-Felddaten, aggregiert nach URL-Gruppen, was es zum idealen Dashboard macht, um im großen Maßstab zu erkennen, welche Templates oder Sektionen Ihrer Website Probleme aufweisen.

Der empfohlene Arbeitsablauf:

Search Console, um zu identifizieren, welche URL-Gruppen nicht bestehen.
PageSpeed Insights, um zu diagnostizieren, warum eine repräsentative URL versagt.
Lighthouse / DevTools, um Korrekturen lokal zu iterieren.
Deployment durchführen und warten, bis der 28-Tage-gleitende Durchschnitt von CrUX die Verbesserung erfasst.

Dieser letzte Punkt ist entscheidend: Da CrUX ein 28-Tage-Durchschnitt ist, spiegelt sich eine Korrektur nicht sofort wider. Geduld ist erforderlich – und gute Änderungen sollten nicht aus Ungeduld rückgängig gemacht werden.

Wie Sie jede Metrik Schritt für Schritt optimieren

Jeder Core Web Vital hat unterschiedliche Ursachen und daher unterschiedliche Lösungen. Dies ist eine nach typischer Wirkung priorisierte Checkliste.

LCP optimieren (<= 2,5 s)

Der LCP ist häufig durch die Zeit begrenzt, die das Hauptelement (in der Regel ein Hero-Bild, ein großer Textblock oder ein Video) zum Laden und Rendern benötigt.

Das LCP-Bild mit Priorität bereitstellen (fetchpriority="high") und Lazy-Loading für dieses spezifische Element vermeiden.
Bildformat optimieren (AVIF oder WebP) und korrekte Dimensionierung für jeden Breakpoint sicherstellen.
Kritische Ressourcen vorladen (Schriftarten, Hero-Bild) und rendering-blockierende Ressourcen eliminieren.
Server-Antwortzeit (TTFB) reduzieren durch Caching, CDN und effizientes Rendering.
Kritisches CSS und JavaScript minimieren, das die erste Darstellung verzögert.

INP optimieren (<= 200 ms)

INP bricht fast immer aufgrund von JavaScript zusammen, das den Haupt-Thread blockiert, wenn der Nutzer interagiert.

Lange Aufgaben (Long Tasks) aufteilen in kleinere Fragmente, um den Thread nicht zu blockieren.
Nicht wesentliches JavaScript von Drittanbietern verzögern oder eliminieren (Chats, Widgets, schwere Marketing-Tags).
content-visibility verwenden und verzögertes Rendering für Inhalte außerhalb des Sichtbereichs.
Unnötige Re-Renders vermeiden in Frameworks wie React durch Optimierung von State und Memoization.
Sofortiges visuelles Feedback bei der Interaktion geben, auch wenn die Verarbeitung im Hintergrund weiterläuft.

CLS optimieren (<= 0,1)

CLS ist das „günstigste" Problem zu beheben und das, was den Nutzer am meisten stört: Elemente, die springen, genau wenn er klicken möchte.

Platz für Bilder und Videos reservieren mit width- und height-Attributen oder aspect-ratio.
Platz für Anzeigen und Einbettungen reservieren, bevor sie geladen werden.
Schriftarten vorladen und font-display: optional oder swap verwenden, um Text-Reflows zu vermeiden.
Niemals Inhalte über vorhandenem Inhalt einfügen, außer als direkte Reaktion auf eine Benutzeraktion.
Mit transform animieren, nicht mit Eigenschaften, die eine Layout-Neuberechnung auslösen.

Diese Art von Arbeit – Messung mit Felddaten, Performance-Budgets und priorisierte Korrekturen – ist genau das, was wir in einem gut geführten Projekt für technisches SEO angehen, wo Performance aufhört, ein punktuelles Problem zu sein, und zum kontinuierlichen Qualitätsstandard wird. Wenn das Problem in der Code-Basis liegt, lösen wir es auf der Ebene der Webentwicklung, indem wir in die Front-End-Architektur, das Rendering und die Ressourcenbereitstellung eingreifen.

Beeinflussen Core Web Vitals wirklich das Ranking?

Das ist die entscheidende Frage, und die ehrliche Antwort hat zwei Teile.

Ja, sie sind ein Ranking-Signal, aber nicht das wichtigste. Gemäß der Google Search Central-Dokumentation zu Core Web Vitals bestätigt Google, dass die Seitenerfahrung – einschließlich der Core Web Vitals – eines von vielen Signalen ist, die sein System bewertet. In derselben Quelle betont Google ausdrücklich, dass großartiger Inhalt weiterhin Vorrang vor der Seitenerfahrung hat.

So lässt sich das in eine realistische Strategie übersetzen:

Core Web Vitals werden mittelmäßige Inhalte nicht über exzellente Inhalte positionieren. Aber wenn zwei Seiten mit vergleichbar hochwertigem Inhalt konkurrieren, kann die Seitenerfahrung der ausschlaggebende Faktor sein – und vor allem derjenige, der bestimmt, ob der ankommende Besucher bleibt und konvertiert.

Daher ist der richtige Ansatz nicht, einen Lighthouse-Score von 100 als Selbstzweck anzustreben, sondern:

Zunächst wertvolle Inhalte sicherstellen, die der Suchabsicht entsprechen.
Core Web Vitals beim 75. Perzentil realer Nutzer als nicht verhandelbaren Qualitätsstandard bestehen.
Performance als Geschäftsvariable behandeln, nicht nur als SEO-Angelegenheit, aufgrund ihres nachgewiesenen Einflusses auf Conversion und Kundenbindung.

Das größte Risiko ist nicht, ein paar Zehntel unter dem Schwellenwert zu liegen: Es ist, Felddaten völlig zu ignorieren und Monat für Monat zu entdecken, warum Nutzer abspringen, ohne dass die Labordaten eine Erklärung liefern.

Sie möchten wissen, wo Ihre Website an Performance verliert und was Sie das an Conversion kostet? Bei Technova Partners auditieren wir Ihre Core Web Vitals mit echten Felddaten, priorisieren Korrekturen nach Wirkung und setzen sie um, bis das 75. Perzentil bestanden ist. Sprechen Sie mit unserem Team und machen Sie Web-Performance zu einem messbaren Wettbewerbsvorteil.