Core Web Vitals 2026: Was Website-Betreiber wissen müssen

Google nutzt drei Metriken, LCP, INP und CLS, um die Nutzererfahrung deiner Website zu bewerten. Wer diese Werte nicht im grünen Bereich hat, verliert Ranking-Positionen. Was hinter den drei Metriken steckt und welche Stellschraube an welcher davon dreht.

Von Dennis Theis 13.01.2026 aktualisiert 16.09.2026 5 Min. Lesezeit

Analytics-Dashboard mit Diagrammen und Leistungskennzahlen auf einem Bildschirm

Ein WooCommerce-Shop aus meinem eigenen Bestand lag beim LCP bei 4,8 Sekunden. Nach drei gezielten Eingriffen (Hero-Bild mit fetchpriority, Font-Preload und JavaScript-Deferring) waren es 1,6 Sekunden, der Lighthouse-Score ging von 52 auf 96. Kein Relaunch, keine neuen Server, nur die richtigen Stellschrauben. Dass auch eine selbst gebaute Seite dort landet, liegt an dem, was im Betrieb dazukommt: Produktbilder, Schriftschnitte, Skripte von Drittanbietern.

Diese Stellschrauben sind die Core Web Vitals: LCP, INP und CLS. Drei Metriken, die Google seit 2021 als Ranking-Faktor nutzt. Wer sie ignoriert, verliert Positionen, egal wie gut der Content ist.

LCP: Largest Contentful Paint

LCP misst, wie lange es dauert, bis das größte sichtbare Element im Viewport geladen ist, typischerweise ein Hero-Bild oder eine große Überschrift. Der Zielwert liegt bei unter 2,5 Sekunden.

Häufige LCP-Probleme

Unoptimierte Bilder: Hero-Bilder ohne fetchpriority="high" und loading="eager"
Render-blockierende Ressourcen: Große CSS- oder JavaScript-Dateien im <head>
Langsame Server-Antwortzeiten: TTFB über 800ms deutet auf Server-Probleme hin
Web-Fonts: Fehlende font-display: swap Deklaration verzögert die Textdarstellung

LCP optimieren: Schritt für Schritt

Hero-Bild priorisieren: fetchpriority="high" und loading="eager" auf dem LCP-Element setzen
Bilder in WebP/AVIF: WebP-Dateien sind laut Google-Studie im Median 25–34% kleiner als vergleichbare JPEGs, AVIF liegt bei gleicher Qualität noch einmal darunter
Fonts preloaden: Kritische Schriften mit <link rel="preload"> im <head>
JavaScript aufschieben: Nicht-kritisches JS mit defer oder dynamischen Imports laden

Bei WordPress-Websites bringen die vier Punkte oben den Großteil. Ein Caching-Plugin kommt danach und deckt vor allem die Serverzeit ab, es ersetzt keinen der vier Schritte. Was ein Cache leistet und was nicht, steht im Artikel zu WordPress-Performance; dass auch ein etabliertes Plugin ausfallen kann, zeigte der WP-Rocket-Fehler nach WordPress 7.1.

INP: Interaction to Next Paint

INP hat 2024 den älteren FID (First Input Delay) abgelöst und misst die Reaktionsfähigkeit einer Website über die gesamte Lebensdauer einer Seite. Der Zielwert liegt bei unter 200 Millisekunden.

Während FID nur die erste Interaktion gemessen hat, erfasst INP jede Interaktion: Klicks, Taps und Tastatureingaben. Der schlechteste Wert (abzüglich Ausreißer) wird als INP gemeldet.

Was wirklich gegen schlechten INP hilft

Der Hauptverursacher ist fast immer zu viel JavaScript, das auf einmal ausgeführt wird. Bei WordPress-Seiten mit Elementor sehe ich regelmäßig 400+ KB JS, die beim Seitenaufruf geparst werden, auch für Sections, die der Nutzer nie sehen wird.

Die wirksamste Maßnahme: JavaScript nur dort laden, wo es gebraucht wird. Astro macht das mit Islands Architecture: statische Sections liefern null JS, nur interaktive Elemente (Accordion, Formulare) bekommen ihr eigenes Bundle. Bei WordPress erreiche ich das gleiche Ergebnis über das load:on-Attribut meines Block-Frameworks: Jeder Block deklariert selbst, wann sein Script geladen wird. Der Standard load:on="visible" hängt es an einen IntersectionObserver und lädt erst, wenn der Block in den Viewport scrollt, daneben gibt es load, idle und interaction. Wie das aufgebaut ist, steht in Custom Gutenberg Blocks mit Timber und Twig.

CLS: Cumulative Layout Shift

CLS misst, wie stark sich sichtbare Elemente während des Ladevorgangs verschieben. Nichts frustriert Nutzer mehr als ein Button, der im letzten Moment wegspringt. Der Zielwert liegt bei unter 0,1.

CLS vermeiden

Bild-Dimensionen angeben: Immer width und height Attribute setzen
Font-Display: font-display: swap mit ähnlichen Fallback-Fonts verwenden
Platzhalter reservieren: Für dynamisch geladene Inhalte feste Höhen oder aspect-ratio definieren
Keine Elemente über dem Fold einfügen: Cookie-Banner und Notices nicht den Content verschieben lassen

Tools zur Messung

Google stellt mehrere kostenlose Tools zur Verfügung, um Core Web Vitals zu messen und Probleme zu identifizieren:

PageSpeed Insights: Kombiniert Lab-Daten (simuliert) und Field-Daten (echte Nutzer)
Google Search Console: Zeigt Core Web Vitals für alle indexierten Seiten
Chrome DevTools → Lighthouse: Detaillierte Analyse mit konkreten Optimierungsvorschlägen
Web Vitals Chrome Extension: Echtzeit-Anzeige der Metriken beim Browsen

Wichtig: Lab-Daten (Lighthouse) und Field-Daten (CrUX) können sich unterscheiden. Field-Daten spiegeln die tatsächliche Nutzererfahrung wider und sind für das Google-Ranking ausschlaggebend.

Und noch ein Detail, das oft untergeht: Google bewertet nicht den Durchschnitt, sondern das 75. Perzentil der echten Seitenaufrufe. Eine Seite besteht eine Metrik erst, wenn 75% der Aufrufe im grünen Bereich liegen. Ein guter Lighthouse-Wert auf dem eigenen Laptop sagt deshalb wenig darüber aus, wie die Seite auf Mobilgeräten im Mobilfunknetz abschneidet.

Warum moderne Frameworks helfen

Klassische Websites laden oft das gesamte JavaScript einer Seite auf einmal, auch für Elemente, die der Nutzer nie sieht. Moderne Frameworks wie Astro oder Next.js lösen dieses Problem mit unterschiedlichen Ansätzen.

Astro nutzt Islands Architecture: Statisches HTML wird serverseitig gerendert, und JavaScript wird nur für tatsächlich interaktive Komponenten geladen. Für rein statische Inhalte geht damit praktisch kein JavaScript an den Browser. Was am Ende im Lighthouse steht, hängt trotzdem an Hosting, Bildern und den Skripten, die später dazukommen.

Der Fehler, den fast alle machen

Die meisten optimieren einmal, freuen sich über den grünen Lighthouse-Score, und schauen nie wieder hin. Drei Monate später hat irgendein Plugin-Update eine neue 200-KB-Datei eingeschleust, der Marketing-Kollege hat ein Tracking-Pixel eingefügt, und der LCP liegt wieder bei 3,5 Sekunden. Ohne es zu merken.

Core Web Vitals brauchen laufendes Monitoring. Nicht täglich, aber mindestens monatlich ein Blick in die Google Search Console. Bei meinen Wartungskunden prüfe ich die Werte bei jedem Update-Zyklus mit. Wenn etwas abrutscht, fange ich es auf bevor Google es tut.

Quellen

web.dev: Web Vitals (Schwellenwerte LCP 2,5 s, INP 200 ms, CLS 0,1, Bewertung am 75. Perzentil)
web.dev: INP löst FID als Core Web Vital ab (wirksam seit 12. März 2024)
web.dev: Optimize Largest Contentful Paint (TTFB-Richtwert unter 800 ms)
Google: WebP Compression Study (WebP-Dateien sind im Median 25–34% kleiner als vergleichbare JPEGs)

Dennis Theis

Freiberuflicher Webentwickler aus Berlin. Schwerpunkt sind Websites, die an die Systeme angebunden sind, in denen die Daten schon liegen.

Mehr über meine Arbeitsweise