Core Web Vitals 2026: LCP, INP und CLS verstehen und verbessern

Google bewertet die Qualität einer Website längst nicht mehr nur an Inhalten und Backlinks. Seit 2021 fließen die Core Web Vitals direkt ins Ranking ein - und mit dem Core-Update vom März 2026 hat Google die Gewichtung der Nutzererfahrung weiter erhöht. Wer hier schlecht abschneidet, verliert Sichtbarkeit. Wer gut abschneidet, gewinnt Besucher und Umsatz.

Die Zahlen zeigen, wie viel Luft nach oben besteht: Laut dem Chrome User Experience Report (CrUX) bestehen Stand 2026 nur rund 56 Prozent aller erfassten Domains alle drei Core Web Vitals gleichzeitig. Fast die Hälfte aller Websites verschenkt also Ranking-Potenzial. In diesem Artikel erkläre ich dir, was die drei Metriken bedeuten, welche Schwellenwerte 2026 gelten, wie du deine Werte misst - und mit welchen Maßnahmen du sie wirklich verbesserst.

Was sind die Core Web Vitals?

Core Web Vitals sind drei standardisierte Kennzahlen, mit denen Google die reale Nutzererfahrung einer Seite bewertet: Ladezeit, Reaktionsschnelligkeit und visuelle Stabilität. Wichtig zu verstehen: Google misst nicht den Durchschnitt, sondern das 75. Perzentil deiner echten Besucher. Das heißt, mindestens 75 Prozent aller Seitenaufrufe müssen den jeweiligen Schwellenwert erreichen, damit eine Seite als "gut" gilt. Ein paar schnelle Aufrufe genügen also nicht - die breite Masse deiner Nutzer muss eine gute Erfahrung machen.

Die drei Metriken und ihre Schwellenwerte im Überblick (Stand 2026, unverändert seit 2024):

• LCP (Largest Contentful Paint) - Ladezeit des größten sichtbaren Inhalts. Gut: unter 2,5 Sekunden.
• INP (Interaction to Next Paint) - Reaktionsgeschwindigkeit auf Interaktionen. Gut: unter 200 Millisekunden.
• CLS (Cumulative Layout Shift) - Visuelle Stabilität des Layouts. Gut: unter 0,1.

Diese Schwellenwerte hat Google für 2026 nicht verändert. Neu ist lediglich, dass die Metriken stärker ins Ranking einfließen. Wenn du eine neue Website planst oder eine bestehende überarbeiten lässt, gehören diese Werte von Anfang an in die technische Webentwicklung - nachträglich nachzubessern ist immer teurer als sauber zu starten.

LCP - Largest Contentful Paint: die Ladezeit

Der LCP misst, wie lange es dauert, bis der größte sichtbare Inhalt im sichtbaren Bereich (Viewport) geladen ist. Das kann ein Hero-Bild, eine große Überschrift oder ein Video-Thumbnail sein. Googles Schwellenwert: unter 2,5 Sekunden ist gut, über 4 Sekunden ist schlecht.

Der LCP ist 2026 die Metrik, an der die meisten Websites scheitern. Während rund 87 Prozent der Seiten beim INP und 81 Prozent beim CLS gut abschneiden, erreichen nur etwa 69 Prozent einen guten LCP-Wert. Wenn deine Seite ein Core-Web-Vitals-Problem hat, beginnt die Suche fast immer hier. Typische Ursachen:

• Unkomprimierte Bilder - Ein Hero-Bild mit 2 MB statt 200 KB verzögert den LCP um Sekunden. Moderne Formate wie WebP oder AVIF reduzieren die Dateigröße um 50 bis 80 Prozent bei gleicher Qualität.
• Render-blockierende Ressourcen - CSS und JavaScript, die im Head geladen werden, blockieren das Rendering der gesamten Seite. Kritisches CSS gehört inline in den Head, der Rest sollte asynchron nachladen.
• Langsame Serverantworten - Wenn der Server 800 Millisekunden für die erste Antwort braucht (Time to First Byte), kann der LCP nicht unter 2,5 Sekunden liegen. Statisch ausgelieferte Seiten, ein CDN oder serverseitiges Caching lösen das Problem.
• Lazy Loading des LCP-Elements - Ein häufiger Fehler: Das Hero-Bild lädt mit loading="lazy". Das verzögert genau das Element, das am schnellsten sichtbar sein sollte. Das LCP-Element sollte immer eager laden, idealerweise zusätzlich per fetchpriority="high" priorisiert.
• Fehlendes Preloading kritischer Ressourcen - Wenn der Browser erst spät erfährt, dass er ein bestimmtes Bild oder eine Schrift braucht, geht Zeit verloren. link rel="preload" für das LCP-Bild und die wichtigste Web-Font schafft Abhilfe.

INP - Interaction to Next Paint: die Reaktionszeit

INP hat im März 2024 den First Input Delay (FID) als Core Web Vital abgelöst und misst etwas deutlich Aussagekräftigeres: die tatsächliche Reaktionsgeschwindigkeit der gesamten Seite über den kompletten Besuch hinweg. Nicht nur die erste Interaktion, sondern jeden Klick, Tap und Tastendruck. Googles Schwellenwert: unter 200 Millisekunden ist gut, über 500 Millisekunden ist schlecht.

INP erfasst die Zeitspanne vom Moment der Interaktion bis zum nächsten sichtbaren Update auf dem Bildschirm. Rund 87 Prozent der Seiten erreichen hier einen guten Wert - trotzdem ist INP nach dem LCP die zweithäufigste Schwachstelle, weil moderne JavaScript-lastige Seiten den Hauptthread (Main Thread) schnell überlasten. Häufige Stolperfallen:

• Lange Tasks im Hauptthread - Jede JavaScript-Aufgabe, die länger als 50 Millisekunden läuft, blockiert die Seite und verzögert die Reaktion auf Eingaben. Die Lösung: lange Aufgaben in kleinere Häppchen aufteilen und dem Browser zwischendurch die Kontrolle zurückgeben. Dafür gibt es seit 2024 die moderne Browser-API scheduler.yield(), alternativ funktioniert auch setTimeout().
• Schwere JavaScript-Frameworks - Jedes Kilobyte JavaScript, das ausgeführt werden muss, kostet Reaktionszeit. Schlanke Ansätze wie Astro oder Svelte, die nur minimales JavaScript an den Browser ausliefern, haben hier einen strukturellen Vorteil gegenüber schweren SPA-Frameworks.
• Event-Handler ohne Drosselung - Scroll- und Resize-Events, die bei jeder Auslösung schwere Berechnungen starten, lassen die Seite ruckeln. Debouncing oder requestAnimationFrame entlasten den Hauptthread.
• Third-Party-Skripte - Analytics, Chat-Widgets, Tracking-Pixel: Jedes externe Skript konkurriert um Rechenzeit. Lade sie asynchron, verzögert oder gar nicht und prüfe ehrlich, welche du wirklich brauchst.

CLS - Cumulative Layout Shift: die visuelle Stabilität

CLS misst, wie stark sich das Layout während des Ladens unerwartet verschiebt. Jedes Mal, wenn ein Element springt - weil ein Bild ohne reservierten Platz nachlädt, ein Banner eingeblendet wird oder eine Schrift nachgeladen wird - zählt das als Layout Shift. Googles Schwellenwert: unter 0,1 ist gut, über 0,25 ist schlecht.

Du kennst das selbst: Du willst auf einen Button tippen, und im letzten Moment rutscht er nach unten, weil darüber etwas erscheint. Genau dieses Frust-Erlebnis misst CLS. Die häufigsten Verursacher:

• Bilder und Videos ohne Dimensionen - Ohne width und height (oder ein aspect-ratio im CSS) weiß der Browser nicht, wie viel Platz er reservieren soll. Sobald die Datei lädt, verschiebt sich alles darunter.
• Dynamisch eingefügte Inhalte - Cookie-Banner, Newsletter-Popups oder nachgeladene Werbung, die bestehenden Inhalt verschieben, statt ihn zu überlagern. Reserviere für solche Elemente festen Platz oder zeige sie als Overlay.
• Web-Font-Rendering - Wenn die Seite erst mit einer Fallback-Schrift rendert und dann zur eigenen Schrift wechselt, springen Textblöcke. font-display: swap in Kombination mit passenden Fallback-Metriken (size-adjust) verhindert das.
• Animationen über layout-relevante Eigenschaften - Animiere mit transform und opacity statt mit top, left oder height. Letztere lösen ein erneutes Layout aus und können CLS verursachen.

Warum Core Web Vitals dein Geschäft beeinflussen

Core Web Vitals sind kein reines SEO-Thema. Sie wirken direkt auf deinen Umsatz, weil schnelle, stabile Seiten schlicht besser konvertieren. Studien zeigen seit Jahren denselben Zusammenhang: Schon eine Sekunde längere Ladezeit kostet im Schnitt rund 7 Prozent Conversions. Für einen Online-Shop mit 100.000 Euro Monatsumsatz sind das rechnerisch 7.000 Euro - jeden Monat.

Dazu kommt der indirekte Hebel über das Ranking: Bessere Core Web Vitals führen zu besseren Positionen, bessere Positionen zu mehr organischem Traffic und mehr Traffic zu mehr Conversions. Ein positiver Kreislauf, der sich selbst verstärkt. Umgekehrt gilt dasselbe nach unten - eine langsame Seite verliert Sichtbarkeit und Besucher zugleich.

So misst du deine Core Web Vitals

Du brauchst kein teures Tool. Wichtig ist nur, den Unterschied zwischen zwei Datenarten zu kennen: Labordaten (Lab Data) entstehen unter simulierten Bedingungen, Felddaten (Field Data) stammen von echten Nutzern. Google bewertet ausschließlich die Felddaten. Ein entscheidender Punkt: INP lässt sich im Labor gar nicht messen, weil es echte menschliche Interaktion voraussetzt - dafür brauchst du zwingend Felddaten.

• PageSpeed Insights - Liefert Labordaten und, falls vorhanden, Felddaten aus dem CrUX-Report. Die Felddaten zeigen dir, wie echte Nutzer deine Seite erleben.
• Google Search Console - Der Bericht "Core Web Vitals" zeigt, welche Seiten gut, verbesserungswürdig oder schlecht abschneiden, gruppiert nach Problem. Ideal, um gezielt die größten Baustellen zu finden.
• Chrome DevTools - Der Performance-Tab zeigt exakt, welche langen Tasks den Hauptthread blockieren. Unverzichtbar fürs INP-Debugging.
• Web Vitals Extension - Eine Chrome-Erweiterung, die LCP, INP und CLS in Echtzeit anzeigt, während du die Seite nutzt.
• Real User Monitoring (RUM) - Für laufende Überwachung empfiehlt sich ein RUM-Tool, das die Werte deiner echten Besucher kontinuierlich erfasst, statt nur Stichproben zu liefern.

Wenn du es unkompliziert magst, kannst du deine Seite auch mit unserem kostenlosen Website-Check prüfen lassen - der gibt dir einen schnellen Überblick über Performance und Optimierungspotenzial.

Drei Quick Wins für bessere Ladezeiten

Du musst nicht alles auf einmal umbauen. Diese drei Maßnahmen bringen erfahrungsgemäß den größten Effekt bei geringstem Aufwand:

• Bilder optimieren - Konvertiere alle Bilder zu WebP oder AVIF, hinterlege Breite und Höhe im HTML und lade das LCP-Element mit loading="eager" und fetchpriority="high". Das verbessert LCP und CLS gleichzeitig.
• JavaScript aufräumen - Entferne ungenutztes JavaScript, lade Third-Party-Skripte mit async oder defer und teile lange Tasks mit scheduler.yield() auf. Das verbessert vor allem den INP.
• Schriften vorausladen - Nutze link rel="preload" für deine wichtigste Web-Font und setze font-display: swap. Das beschleunigt das Rendering und verhindert Layout Shifts durch Schriftwechsel.

Diese drei Schritte allein können den Unterschied zwischen "schlecht" und "gut" ausmachen - und sie kosten kein Budget, sondern nur etwas Arbeit. Wenn du tiefer einsteigen willst, lohnt sich ein Blick in unseren Guide zum Lighthouse-Score von 100 sowie in den Beitrag zur Website-Performance insgesamt.

Core Web Vitals dauerhaft halten

Ein einmal erreichter guter Wert bleibt nicht automatisch gut. Jedes neue Bild, jedes zusätzliche Tracking-Skript und jede dritte Plugin-Integration kann die Werte wieder verschlechtern. Deshalb gehört Performance nicht in ein einmaliges Projekt, sondern in den laufenden Betrieb: regelmäßige Messungen, ein Auge auf neue Third-Party-Skripte und Tests vor jedem größeren Deployment. Genau das deckt eine kontinuierliche Wartung und Support ab - damit deine Seite schnell bleibt, statt schleichend langsamer zu werden.

Fazit

Die Core Web Vitals sind 2026 fester Bestandteil von Googles Ranking - mit unveränderten Schwellenwerten (LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1), aber höherem Gewicht. Der LCP ist und bleibt die häufigste Schwachstelle, dicht gefolgt vom INP auf JavaScript-lastigen Seiten. Die gute Nachricht: Die wirksamsten Maßnahmen - Bilder optimieren, JavaScript reduzieren und Schriften sauber laden - sind kein Hexenwerk und kosten kein großes Budget.

Wer Performance von Beginn an mitdenkt und kontinuierlich überwacht, statt erst bei einem Ranking-Einbruch zu reagieren, hat klar die Nase vorn. Schnelle Seiten ranken besser, konvertieren besser und machen schlicht den besseren Eindruck.

Häufige Fragen