Core Web Vitals 2026: Praxisleitfaden zur Optimierung
LCP, INP und CLS einfach erklärt – mit den Neuerungen 2026 und konkreten Strategien für eine schnellere, stabilere Website.
Seit 2021 nutzt Google die Core Web Vitals als Ranking-Signal im Rahmen der „Page Experience“. Es sind drei Metriken, und die Grenzwerte haben sich nicht geändert: Was sich 2026 geändert hat, ist vor allem die Art der Messung. Hier erfahren Sie, was sie messen, was neu ist und wie Sie sie konkret verbessern.
Die drei zentralen Metriken
LCP – Largest Contentful Paint
Misst, wie lange es dauert, bis das größte sichtbare Element der Seite (meist das Hauptbild oder ein Textblock) angezeigt wird. Ziel: innerhalb von 2,5 Sekunden. Zwischen 2,5 und 4 Sekunden gilt als „verbesserungswürdig“, darüber als „schlecht“.
INP – Interaction to Next Paint
Hat im März 2024 FID abgelöst. Misst die Reaktionsfähigkeit: wie viel Zeit zwischen einer Interaktion (Klick, Tippen, Eingabe) und der sichtbaren Reaktion der Seite vergeht. Ziel: höchstens 200 Millisekunden. Anders als FID berücksichtigt INP alle Interaktionen eines Besuchs, nicht nur die erste.
CLS – Cumulative Layout Shift
Misst die visuelle Stabilität: wie stark sich Elemente beim Laden der Seite verschieben. Text, der springt, Schaltflächen, die sich genau dann bewegen, wenn man sie antippen will. Ziel: unter 0,1.
Für die Bewertung betrachtet Google das 75. Perzentil der realen Besuche: Mindestens drei von vier Besuchen müssen innerhalb des Grenzwerts bleiben, getrennt für Mobilgeräte und Desktop.
Was sich 2026 ändert
Die wichtigste Neuerung betrifft Websites, die als Single-Page-Applications gebaut sind (React, Vue, Angular und Ähnliche). Bisher ordnete der Browser die Metriken beim Seitenwechsel ohne Neuladen des Dokuments weiterhin der ersten URL zu. Seit Chrome 151, erschienen im August 2026, werden diese „Soft Navigations“ standardmäßig gemessen: Jeder Seitenwechsel erhält eigene LCP-, INP- und CLS-Werte.
Zwei Einschränkungen. Google hat noch nicht festgelegt, wie diese Messungen in den Chrome UX Report einfließen, die Datenbasis von PageSpeed Insights und Search Console. Und die Grenzwerte bleiben die alten: Im Netz kursieren Artikel über einen auf „2 Sekunden gesenkten“ LCP oder eine Bewertung „pro Domain“, doch die offizielle Dokumentation von Google enthält nichts dergleichen.
Die häufigsten Ursachen für einen hohen LCP
- Ein schweres Hauptbild oder eines ohne fetchpriority="high"
- Ein per Lazy Loading geladenes Hauptbild: im sichtbaren Bereich vermeiden
- Schriften, die blockierend von externen Diensten geladen werden
- Hohe TTFB: langsamer Server, kein Caching, kein CDN
- Render-blockierendes CSS und JavaScript im <head>
- Bilder als JPEG oder PNG, wo WebP oder AVIF deutlich leichter wären
So verbessern Sie LCP
Die wirksamste Maßnahme betrifft fast immer das Hauptbild: ein modernes Format (WebP oder AVIF), passende Größen per srcset, fetchpriority="high" und kein Lazy Loading. Ist das Bild im CSS definiert, lässt ein <link rel="preload"> im <head> den Browser es sofort entdecken.
Zweite Priorität: der Server. Eine Seite, die erst nach 1,5 Sekunden ankommt, hat schon mehr als die Hälfte des Budgets verbraucht. Seiten-Caching, Komprimierung und ein CDN senken die TTFB stärker als jede Frontend-Optimierung. Und Schriften auf der eigenen Domain zu hosten spart eine externe Verbindung, die in Mobilfunknetzen besonders teuer ist.
So verbessern Sie INP
INP ist oft die schwierigste Metrik, weil sie davon abhängt, wie viel JavaScript der Browser im Hauptthread ausführt. Diese Strategien funktionieren:
- Skripte von Drittanbietern (Chat, Widgets, Werbe-Pixel) reduzieren und nur dort laden, wo sie gebraucht werden
- Lange Tasks aufteilen und die Kontrolle mit scheduler.yield() an den Browser zurückgeben, wo unterstützt, mit setTimeout als Ausweichlösung
- Sofort ein sichtbares Feedback auf die Interaktion zeigen und aufwendige Arbeit verschieben
- Nicht kritische Skripte mit defer oder async laden
- Riesige DOMs vermeiden: Seiten mit Tausenden von Knoten machen jede Aktualisierung langsam
So verbessern Sie CLS
CLS lässt sich meist am einfachsten beheben. Die meisten Probleme entstehen durch:
- Bilder und Videos ohne width und height: Der Browser reserviert keinen Platz
- Webfonts, die beim Laden die Textgröße verändern: font-display: swap hilft, doch um die Verschiebung zu beseitigen, braucht es eine Ersatzschrift mit ähnlichen Metriken (size-adjust)
- Banner, Anzeigen und Widgets ohne reservierten Platz
- Inhalte, die dynamisch oberhalb des bereits sichtbaren Bereichs eingefügt werden
Bei einem Audit der Website eines Kunden haben wir den CLS von 0,42 auf 0,02 gesenkt – allein durch explizite width- und height-Angaben für alle Bilder und ein korrigiertes Laden der Schriften.
Werkzeuge zur Messung
PageSpeed Insights bleibt der Ausgangspunkt, zeigt aber zwei verschiedene Dinge: Labordaten (eine Simulation) und reale Daten von Chrome-Nutzern der letzten 28 Tage. Für die Bewertung durch Google zählen Letztere. Der Core-Web-Vitals-Bericht in der Search Console gruppiert Seiten mit ähnlichen Problemen, und das Performance-Panel der Chrome DevTools ist unverzichtbar, um die Interaktion hinter einem hohen INP zu finden. Für eine laufende Überwachung erfasst die Bibliothek web-vitals die Metriken direkt bei echten Nutzern.
Fazit
Die Core Web Vitals sind nicht nur Ranking-Metriken: Sie zeigen, wie Besucher Ihre Website tatsächlich erleben. Eine schnelle, stabile Website konvertiert besser und hält Besucher länger. Und Optimierung ist keine einmalige Aufgabe: Sie muss laufend überwacht werden, besonders nach jedem Release oder jeder Aktualisierung der Inhalte.