Was Core Web Vitals sind – und warum sie ranken
Core Web Vitals sind drei messbare Kennzahlen, mit denen Google die wahrgenommene Nutzererfahrung deiner Seite bewertet: wie schnell der Hauptinhalt erscheint, wie flüssig die Seite auf Eingaben reagiert und wie stabil das Layout bleibt. Seit INP im März 2024 FID als Core Web Vital abgelöst hat, fallen viele Seiten durch – und merken es oft erst, wenn die Sichtbarkeit sinkt.
Die drei Metriken heißen LCP (Largest Contentful Paint), INP (Interaction to Next Paint) und CLS (Cumulative Layout Shift). Sie sind Teil des Page-Experience-Signals und damit ein echter Rankingfaktor. Wichtig ist die Größenordnung: Core Web Vitals sind kein Wundermittel, das dich von Platz 40 auf Platz 1 hebt. Aber bei vergleichbarer inhaltlicher Relevanz entscheiden sie das Rennen – und schlechte Werte ziehen dich messbar nach unten, gerade auf Mobilgeräten.
Entscheidend ist, die Datenquellen zu unterscheiden. Field-Daten (auch CrUX, Chrome User Experience Report) sind echte Messwerte deiner realen Besucher über die letzten 28 Tage – und genau diese fließen ins Ranking ein. Lab-Daten (z.B. ein Lighthouse-Lauf) sind eine synthetische Einzelmessung unter Laborbedingungen. Lab-Daten sind super zum Debuggen, aber bewertet wirst du nach dem Feld. Wer nur den grünen Lighthouse-Score feiert, optimiert am Ziel vorbei.
Die Schwellenwerte 2026 im Überblick
Bewertet wird das 75. Perzentil deiner realen Nutzer (Field-Daten)
01. LCP optimieren (Ladezeit des Hauptinhalts)
Der Largest Contentful Paint misst, wann das größte sichtbare Element im Viewport gerendert ist – meist das Hero-Bild, eine große Überschrift oder ein Video-Poster. Ziel sind ≤ 2,5 Sekunden im 75. Perzentil. LCP setzt sich aus vier Bausteinen zusammen: TTFB, Ressourcen-Ladeverzögerung, Ladezeit der Ressource und Render-Verzögerung. Du musst alle vier angreifen.
Server & TTFB
Eine hohe Time to First Byte vergiftet jede weitere Metrik – noch bevor das Bild überhaupt anfängt zu laden, vergehen Sekunden. Setze auf serverseitiges Caching, ein CDN mit Edge-Nodes nahe am Nutzer und – bei dynamischen Seiten – auf ISR (Incremental Static Regeneration) oder SSG in Next.js, damit Google und Nutzer fertiges HTML aus dem Cache bekommen statt eines on-the-fly gerenderten Dokuments. Strebe eine TTFB deutlich unter 600 ms an.
Bilder als häufigster LCP-Sünder
In den meisten Fällen ist das LCP-Element ein Bild. Drei Hebel sind Pflicht: modernes Format (WebP/AVIF statt JPEG/PNG), korrekt dimensionierte Größen über sizes – kein 3000px-Bild in einen 800px-Slot – und das priority-Attribut für das LCP-Bild, damit es nicht lazy-loaded wird. In Next.js erledigt next/image Formatauswahl, responsive Größen und Lazy Loading automatisch; du setzt nur noch priority auf das eine Bild above the fold.
// ❌ BAD: <img> ohne Größe, kein modernes Format, lazy<img src="/hero.jpg" alt="Hero" />// ✅ GOOD: next/image liefert AVIF/WebP, lädt das LCP-Bild zuerstimport Image from "next/image";export default function Hero() { return ( <Image src="/hero.jpg" alt="Marketing ohne Rätselraten" width={1600} height={900} sizes="(max-width: 768px) 100vw, 1600px" priority // kein Lazy Load, früher Preload /> );}Fonts, Preload & Render-Blocking
Web-Fonts blockieren oft den ersten Text-Paint. Nutze next/font, um Schriften selbst zu hosten – das eliminiert eine externe Verbindung zu Google Fonts und setzt automatisch ein sinnvolles font-display. Kritische Ressourcen (LCP-Bild, primärer Font) gehören per preload früh in den Ladepfad. Gleichzeitig gilt: render-blockierendes CSS und synchrones JavaScript im <head> verzögern den Paint. Inline-Critical-CSS und das Defer/Async-Laden nicht kritischer Skripte bringen hier die größten Sprünge.
„Optimiere immer das eine LCP-Element zuerst. Ein einziges nicht priorisiertes Hero-Bild kostet dich häufig mehr Sekunden als alle CSS-Tricks zusammen wieder einbringen.“
02. INP optimieren (Interaktivität)
Interaction to Next Paint misst, wie schnell deine Seite auf eine Eingabe reagiert – Klick, Tap, Tastendruck. Gemessen wird die Latenz von der Interaktion bis zum nächsten sichtbaren Frame, über die gesamte Lebensdauer des Seitenbesuchs. Ziel: ≤ 200 ms. INP ist gnadenloser als das alte FID, weil es nicht nur die erste, sondern alle Interaktionen bewertet und die schlechtesten heranzieht.
Der Main-Thread ist der Engpass
Schlechtes INP hat fast immer eine Ursache: ein blockierter Main-Thread. Wenn der Browser gerade ein MB-schweres JavaScript-Bundle parst, ausführt oder hydratisiert, kann er nicht gleichzeitig auf den Klick des Nutzers reagieren. Die Eingabe wartet in der Queue – und genau das misst INP. Drei Strategien helfen:
- 1JS-Bundles reduzieren: Weniger Code = weniger Parse- und Ausführungszeit. Code-Splitting, dynamische Imports (
next/dynamic) für selten genutzte Komponenten und konsequentes Tree-Shaking schrumpfen den Main-Thread-Druck. Jede nicht ausgelieferte Zeile JavaScript ist die schnellste Zeile. - 2Hydration-Overhead senken: Klassisches Client-Side-Rendering muss die gesamte Seite im Browser „zum Leben erwecken“. Mit React Server Components in Next.js bleibt ein Großteil als reines HTML auf dem Server – es gibt schlicht kein JavaScript, das hydratisiert werden müsste. Mach interaktiv nur, was wirklich interaktiv sein muss.
- 3Lange Tasks aufbrechen: Jede Aufgabe über 50 ms blockiert den Thread. Teile teure Berechnungen mit
scheduler.yield()odersetTimeoutin kleinere Häppchen, lagere schwere Logik in einen Web Worker aus und entkopple nicht-dringende Updates (z.B. viarequestIdleCallback), damit der Browser zwischendurch auf Eingaben reagieren kann.
Der architektonische Königsweg ist klar: weniger clientseitiges JavaScript. Genau deshalb setzen wir bei performancekritischen Projekten auf SSR und Server Components statt auf schwergewichtige Single-Page-Apps. Wie sich das gegen einen klassischen Stack schlägt, vertiefen wir im Beitrag Next.js vs. WordPress.
03. CLS optimieren (Layout-Stabilität)
Cumulative Layout Shift misst, wie stark sichtbare Elemente während des Ladens unerwartet verspringen. Jeder kennt es: Man will auf einen Button tippen, ein nachgeladenes Banner schiebt alles nach unten, und man trifft die falsche Stelle. Ziel: ein CLS-Wert von ≤ 0,1. Gute Nachricht – CLS ist oft die am einfachsten zu fixende Metrik, weil die Ursachen klar benennbar sind.
Maße reservieren
Die häufigste Quelle: Bilder und Videos ohne feste Dimensionen. Wenn der Browser nicht weiß, wie viel Platz ein Medium braucht, rendert er erst nichts und schiebt dann beim Laden alles weg. Gib immer width und height an (oder ein aspect-ratio per CSS) – next/image erzwingt das ohnehin. So wird der Platz reserviert, bevor das Bild da ist.
Dynamische Inhalte, Ads & Fonts
Nachgeladene Werbung, Cookie-Banner, Embeds und A/B-Test-Inhalte sind klassische Layout-Shift-Verursacher. Reserviere für jeden dynamischen Slot von vornherein einen Container mit fixer Mindesthöhe (min-height), damit nichts springt, wenn der Inhalt eintrifft. Auch Fonts spielen mit hinein: Beim Wechsel von der Fallback- zur Web-Schrift kann sich das Layout verschieben (FOUT). Ein gut konfiguriertes font-display – idealerweise über next/font mit passendem Fallback – hält diesen Sprung minimal.
Faustregel: Nie ein Element oberhalb von bereits sichtbarem Inhalt einfügen, außer als direkte Reaktion auf eine Nutzeraktion. Banner, die von oben „reindrücken“, sind CLS-Gift.
04. Richtig messen (Field vs. Lab)
Optimieren ohne Messen ist Raten. Diese vier Werkzeuge gehören in jeden Workflow – und du musst genau wissen, welches Field- und welches Lab-Daten liefert:
- PageSpeed Insights: Kombiniert beides – oben die echten CrUX-Field-Daten deiner Nutzer (das ist die ranking-relevante Wahrheit), darunter ein Lighthouse-Lab-Lauf mit konkreten Optimierungsvorschlägen.
- CrUX / Search Console: Der Core-Web-Vitals-Bericht in der Google Search Console zeigt dir aggregiert über alle URL-Gruppen, welche Seiten im Feld „schlecht“ oder „verbesserungswürdig“ sind – ideal für die Priorisierung.
- Lighthouse / DevTools: Reine Lab-Daten zum Debuggen einzelner Seiten. Perfekt, um die Ursache eines Problems zu isolieren – aber kein Beweis, dass es im Feld auch grün ist.
- web-vitals-JS: Die offizielle Bibliothek von Google misst die Vitals direkt bei deinen echten Nutzern (Real User Monitoring) und schickt sie an dein Analytics-Tool. So bekommst du Field-Daten in Echtzeit statt 28 Tage Verzögerung.
// Field-Daten deiner echten Besucher erfassenimport { onLCP, onINP, onCLS } from "web-vitals";function sendToAnalytics(metric) { // z.B. an GA4 / dein RUM-Endpoint navigator.sendBeacon("/vitals", JSON.stringify(metric));}onLCP(sendToAnalytics);onINP(sendToAnalytics);onCLS(sendToAnalytics);Merke dir die goldene Regel: Im Lab debuggen, im Feld bewerten. Ein grüner Lighthouse-Score auf deinem schnellen Entwickler-Laptop sagt wenig über einen Nutzer mit Mittelklasse-Smartphone im 4G-Netz aus – und genau dessen Erfahrung zählt für Google.
05. Performance-Checkliste
Zusammengefasst – das sind die Hebel, die in der Praxis den größten Unterschied machen, wenn du deine Core Web Vitals in den grünen Bereich bringen willst:
Core Web Vitals sind kein einmaliges Projekt, sondern ein Dauerlauf: Jedes neue Feature, jedes Drittanbieter-Skript und jede Ad-Integration kann deine Werte wieder verschlechtern. Wer Performance von Anfang an in die Architektur einbaut – statt sie nachträglich draufzuschrauben – gewinnt doppelt: bessere Rankings und höhere Conversion. Wenn du eine technisch saubere Basis brauchst, ist genau das unser Spezialgebiet in der Webentwicklung. Und wenn du wissen willst, wo deine Seite insgesamt steht, hilft dir unser Leitfaden zu SEO-Audits 2026 weiter.
Ciyan Gültoplayan
Head of Engineering & SEO bei Werbeexperte. Spezialisiert auf performante Webarchitekturen (React/Next.js) und die Schnittstelle zwischen technischer Infrastruktur und organischem Wachstum.
Auf LinkedIn verbinden