Core Web Vitals 2026: Was Website-Betreiber wissen müssen
Google nutzt drei Metriken, LCP, INP und CLS, um die Nutzererfahrung Ihrer Website zu bewerten. Wer diese Werte nicht im grünen Bereich hat, verliert Ranking-Positionen. Hier erfahren Sie, was hinter den Metriken steckt und wie Sie jede einzelne gezielt optimieren.
Bei einem Kundenprojekt letztes Jahr lag der LCP bei 4,8 Sekunden. Nach drei gezielten Optimierungen (Hero-Bild
mit fetchpriority, Font-Preload und JavaScript-Deferring) waren es 1,6 Sekunden. Der Lighthouse-Score
sprang von 52 auf 96. Kein Relaunch, keine neuen Server, nur die richtigen Stellschrauben.
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"undloading="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: swapDeklaration verzögert die Textdarstellung
LCP optimieren: Schritt für Schritt
- Hero-Bild priorisieren:
fetchpriority="high"undloading="eager"auf dem LCP-Element setzen - Bilder in WebP/AVIF: Moderne Formate sparen 30–50% gegenüber JPEG
- Fonts preloaden: Kritische Schriften mit
<link rel="preload">im<head> - JavaScript aufschieben: Nicht-kritisches JS mit
deferoder dynamischen Imports laden
Bei WordPress-Websites sorgen regelmäßige Updates und ein gut konfiguriertes Caching-Plugin wie WP Rocket für deutliche LCP-Verbesserungen.
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 erreichen wir das gleiche Ergebnis mit unserem
load:on="visible" Attribut, das Scripts erst lädt wenn der Block in den Viewport scrollt.
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
widthundheightAttribute setzen - Font-Display:
font-display: swapmit ähnlichen Fallback-Fonts verwenden - Platzhalter reservieren: Für dynamisch geladene Inhalte feste Höhen oder
aspect-ratiodefinieren - 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.
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. Das Ergebnis sind typischerweise Lighthouse-Scores von 95+ bei nahezu null JavaScript-Overhead für statische Inhalte.
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.