Core Web Vitals 2026: LCP, INP und CLS verständlich erklärt

Core Web Vitals sind drei Messwerte von Google für Ladegeschwindigkeit, Reaktionsfähigkeit und visuelle Stabilität einer Seite: LCP, INP und CLS. Eine Seite besteht, wenn mindestens 75 Prozent der Seitenaufrufe bei allen drei Werten im guten Bereich liegen, also LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1 (web.dev). Das ist wichtig für Nutzer und Conversion, aber kein Hebel, der schlechte Inhalte nach oben trägt.

Welche drei Core Web Vitals gelten 2026?

Die aktuellen Core Web Vitals sind Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). First Input Delay (FID) gehört nicht mehr dazu: INP hat FID im März 2024 als stabiler Core Web Vital abgelöst, und Chrome hat die FID-Unterstützung bis September 2024 auslaufen lassen (web.dev Blog). Wer in alten Berichten noch FID liest, schaut auf eine Metrik, die Google nicht mehr auswertet.

Die Schwellen stammen aus den Metrik-Seiten von web.dev zu LCP, INP und CLS. Gemessen wird jeweils das 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop. Dazwischen liegt der Bereich „verbesserungswürdig“.

Sind Core Web Vitals ein Rankingfaktor?

Core Web Vitals fließen in Googles Rankingsysteme ein, sind aber nur ein Signal von vielen. Google schreibt, es gebe bei der Seitenerfahrung „kein einzelnes Signal“, und gute Werte allein garantierten keine Top-Platzierung. Außerdem wirken andere Aspekte der Seitenerfahrung jenseits der Core Web Vitals laut Google nicht direkt auf das Ranking (Google Search Central: Seitenerfahrung). Google empfiehlt gute Werte ausdrücklich für den Erfolg in der Suche (Google Search Central: Core Web Vitals).

Die Formulierung „Google bestraft langsame Websites“ trifft das also nicht. Realistischer ist: Inhalt und Relevanz entscheiden zuerst, und bei vergleichbaren Seiten kann eine schlechte Nutzererfahrung ein Nachteil sein. Der größere, direkt messbare Effekt liegt meist bei den Besuchern selbst, die eine träge oder springende Seite schneller verlassen. Wie sich das auf deine Anfragen oder Verkäufe auswirkt, kannst du in deinen eigenen Analytics-Daten prüfen, statt Branchenzahlen zu glauben.

Wie misst du Core Web Vitals richtig?

Für die Bewertung zählen Felddaten, also Messwerte echter Nutzer, und Labordaten helfen beim Beheben von Problemen. Felddaten stammen aus dem Chrome User Experience Report (CrUX) und decken einen Zeitraum von 28 Tagen ab, weshalb eine Verbesserung erst verzögert sichtbar wird. Labordaten wie bei Lighthouse laufen auf einem simulierten Gerät und sind reproduzierbar, bilden die Vielfalt echter Nutzer aber nicht ab. web.dev empfiehlt, mit Felddaten Prioritäten zu setzen und mit Labordaten zu debuggen (web.dev: Lab- und Felddaten).

In der Praxis nutzt du drei Stellen:

• Search Console: Der Core-Web-Vitals-Bericht zeigt, wie deine Seiten abschneiden (Google Search Central).
• PageSpeed Insights: Zeigt CrUX-Felddaten und Labordaten für eine einzelne URL.
• Echtnutzer-Messung (RUM): Mit der JavaScript-Bibliothek web-vitals misst du INP direkt bei deinen Besuchern und findest die konkrete Interaktion, die bremst (web.dev: INP).

Bei wenig Traffic können CrUX-Daten für einzelne URLs fehlen. Dann ist die Messung auf Ebene der gesamten Domain oder ein eigenes RUM-Skript die bessere Grundlage.

Was ist neu im Herbst 2026? Soft Navigations in CrUX

Seit dem 13. Oktober 2026 veröffentlicht Chrome im CrUX experimentelle Varianten von LCP, INP und CLS, die auch Soft Navigations erfassen. Eine Soft Navigation ist ein Seitenwechsel innerhalb einer Single-Page-App, bei dem der Browser keine neue HTML-Seite lädt. Laut den CrUX-Release-Notes haben mit Soft Navigations 59,5 Prozent der Origins gute Core Web Vitals, ohne sie 55,9 Prozent (Chrome CrUX Release Notes). Die stabilen Metriken und ihre Schwellen bleiben unverändert. Für klassische Websites, die bei jedem Klick eine neue Seite laden, ändert sich dadurch nichts. Betreibst du eine React- oder Vue-App mit clientseitigem Routing, lohnt ein Blick in die neuen Werte.

Wie verbesserst du LCP, INP und CLS konkret?

LCP: das größte Element früh laden

LCP setzt sich aus vier Teilen zusammen: Time to First Byte, Verzögerung vor dem Laden der Ressource, Ladedauer der Ressource und Verzögerung beim Rendern. web.dev nennt als Richtwert etwa 40 Prozent für TTFB, etwa 40 Prozent für die Ladedauer und je unter 10 Prozent für die beiden Verzögerungen (web.dev: LCP optimieren). Die wichtigsten Hebel laut web.dev:

• Das LCP-Bild steht im ursprünglichen HTML und bekommt fetchpriority=“high“. Wird es nur per CSS oder JavaScript eingebunden, hilft ein Preload.
• Das LCP-Bild wird nie per Lazy Loading verzögert.
• Bilder sind passend skaliert, modern komprimiert und werden über ein CDN ausgeliefert.
• Render-blockierende Stylesheets und Skripte im head werden reduziert, Weiterleitungen vermieden.

INP: den Hauptthread freihalten

INP ist die längste Reaktionszeit einer Seite auf Klicks, Taps und Tastatureingaben während eines Besuchs, wobei ein Ausreißer pro 50 Interaktionen ignoriert wird. Sie besteht aus Input Delay, Verarbeitungszeit der Event-Handler und Präsentationsverzögerung bis zum nächsten gezeichneten Frame (web.dev: INP). Typische Maßnahmen laut web.dev:

• Lange Tasks beim Seitenstart vermeiden, weil sie Eingaben blockieren.
• Event-Callbacks schlank halten und längere Arbeit aufteilen, damit der Browser zwischendurch zeichnen kann.
• Das DOM klein halten und große Mengen HTML nicht clientseitig per JavaScript rendern.

In WordPress- und WooCommerce-Shops können Plugins, Tracking-Skripte und Chat-Widgets den Hauptthread belasten, weil sie zusätzliches JavaScript mitbringen. Ein Blick in die Skriptliste zeigt oft schneller Ergebnisse als jede Feinoptimierung am Theme.

CLS: Platz reservieren

CLS misst das größte zusammenhängende Bündel unerwarteter Layout-Verschiebungen. Die häufigsten Ursachen laut web.dev sind Bilder und Videos ohne Größenangabe, nachladende Schriften und Werbe- oder Widget-Elemente, die ihre Größe nachträglich ändern (web.dev: CLS). Gegenmittel (web.dev: CLS optimieren):

• width und height bei Bildern und Videos setzen oder aspect-ratio nutzen.
• Für Anzeigen, Embeds und Banner feste Mindesthöhen reservieren.
• Webfonts mit passender Fallback-Schrift und font-display-Strategie laden.
• Animationen mit transform statt mit top oder left umsetzen.

Welche Fehler kosten bei der Optimierung am meisten Zeit?

Die meisten Fehlversuche entstehen, weil an der falschen Stelle gemessen oder an der falschen Stelle optimiert wird. Vier Muster tauchen immer wieder auf:

• Nur Lighthouse prüfen: Ein gutes Lab-Ergebnis sagt wenig über echte Nutzer, denn Felddaten enthalten andere LCP-Elemente, Caching und echte Interaktionen (web.dev).
• Nur den Desktop betrachten: Die Werte werden getrennt nach Mobil und Desktop bewertet. Ein gutes Desktop-Ergebnis sagt deshalb nichts über die mobile Bewertung.
• INP nur im Ruhezustand testen: web.dev rät, Interaktionen auch während des Seitenladens zu testen, weil der Hauptthread dann am stärksten ausgelastet ist (web.dev: INP).
• Das LCP-Bild per Lazy Loading laden: Das verzögert genau das Element, das die Metrik bestimmt. web.dev sagt dazu klar, dass du das LCP-Bild nie lazy laden sollst.

Ein weiterer Punkt ist der Zurück-Button. Seiten, die für den Back/Forward-Cache (bfcache) geeignet sind, werden beim Zurücknavigieren direkt wiederhergestellt, ohne dass erneut Layout-Verschiebungen entstehen (web.dev: CLS optimieren). Dass deine Seiten dafür geeignet sind, solltest du bei einem technischen Audit mitprüfen.

Bleib außerdem realistisch bei der Erwartung. Wenn nach einer Optimierung die Besucherzahl nicht sofort steigt, liegt das häufig daran, dass Core Web Vitals nur ein Signal unter vielen sind. Der verlässlichere Gewinn ist eine Website, die sich für Besucher schnell und stabil anfühlt. Das lässt sich über Absprungrate, Seitenaufrufe pro Besuch und die Zahl der abgeschlossenen Formulare in deinen eigenen Daten überprüfen.

In welcher Reihenfolge gehst du vor?

Am wirksamsten ist eine feste Reihenfolge, die zuerst die Messung und dann die größten Engpässe angeht. So gehst du vor:

1. Search Console öffnen und prüfen, welche Seitengruppen bei Mobil als „schlecht“ oder „verbesserungswürdig“ markiert sind.
2. Die umsatz- oder anfragerelevanten Vorlagen priorisieren, etwa Startseite, Produktseite, Kontaktformular.
3. Pro Vorlage die schwächste Metrik in PageSpeed Insights ansehen und im Lab reproduzieren.
4. Eine Ursache nach der anderen beheben, zum Beispiel das LCP-Bild, ein schweres Skript oder fehlende Bildmaße.
5. Nach der Änderung 28 Tage Felddaten abwarten und erst dann bewerten.

Für die Umsetzung brauchst du Zugriff auf Theme, Plugins und Server. Wenn du das nicht selbst anfassen willst, übernimmt das unser Team für Webdesign und technisches SEO aus einer Hand, bei Shops auch für WooCommerce. Wie sich strukturierte Daten und Performance gemeinsam auf deine Darstellung in der Suche auswirken, liest du in unserem Beitrag zu Schema Markup.

Was gilt für KI-Antworten und AI Overviews?

Auch für Googles KI-Funktionen zählt die Seitenerfahrung als Teil der SEO-Grundlagen. Google nennt in seinem Leitfaden zu AI Overviews und AI Mode ausdrücklich eine gute Seitenerfahrung neben Crawlbarkeit und Textinhalten als Best Practice (Google Search Central: KI-Funktionen). Mehr dazu in unserem Beitrag zu Google AI Overviews.