Core Web Vitals: Der komplette SEO-Leitfaden (2026)

Jeder SEO-Blog hat einen Core-Web-Vitals-Artikel. Was in der Praxis verwirrt: Eine Seite kann in PageSpeed Insights schlecht abschneiden und für echte Besucher trotzdem schnell sein. In Luminas PageSpeed-Studie zu 47 DACH-Nachrichtenseiten, gemessen am 17.09.2026, hatten alle 47 in den Felddaten einen guten LCP (Median 1,3 s). Der Median des mobilen Labor-Scores lag dagegen bei 52. Dieselben Seiten am selben Tag, zwei völlig unterschiedliche Antworten.

Core Web Vitals sind drei Kennzahlen, an denen Google misst, wie eine Seite für echte Nutzer wirkt. Largest Contentful Paint (LCP) zeigt, wann der Hauptinhalt sichtbar wird. Interaction to Next Paint (INP) erfasst, wie schnell die Seite auf Klicks und Taps reagiert. Cumulative Layout Shift (CLS) erfasst, wie stabil das Layout während des Ladens bleibt. Die Werte kommen aus Chrome-Felddaten echter Nutzer über rollierende 28 Tage, nicht aus einer Laborsimulation auf einer einzelnen Maschine.

Was Core Web Vitals wirklich messen

Largest Contentful Paint (LCP): wann der Hauptinhalt erscheint

LCP ist die Zeit vom Start des Ladevorgangs bis zum Moment, in dem das größte sichtbare Element im Viewport fertig gerendert ist. Dieses Element ist meistens das Hero-Bild, die Haupt-Überschrift oder ein großer Textblock. Es ist der Moment, in dem der Nutzer zum ersten Mal das Gefühl hat: „Ok, die Seite ist da.“

Guter LCP: 2,5 Sekunden oder weniger im 75. Perzentil. Schlecht: mehr als 4 Sekunden. Die meisten Seiten, die beim LCP scheitern, scheitern an einer von vier Ursachen: ein nicht optimiertes Hero-Bild (zu groß, falsches Format, kein fetchpriority="high"), render-blockierende Third-Party-Skripte, langsame Server-Antwortzeiten (TTFB) oder eine Web-Font, die den Text-Render blockiert.

Interaction to Next Paint (INP): wie schnell die Seite reagiert

INP misst die Latenz jeder Nutzer-Interaktion auf der Seite: Klicks, Taps, Tastendrücke. Es erfasst die ganze Strecke vom Input-Event bis zum nächsten Paint, der die Aktion sichtbar bestätigt, inklusive Event-Handler-Zeit, DOM-Updates, Style- und Layout-Neuberechnung und Paint. Gemeldet wird die langsamste Interaktion auf der Seite. Bei Seiten mit sehr vielen Interaktionen lässt Google pro 50 Interaktionen die höchste weg, damit ein einzelner Ausreißer in einer langen Sitzung nicht den Wert bestimmt.

Guter INP: 200 Millisekunden oder weniger. Schlecht: mehr als 500 ms. INP hat First Input Delay (FID) am 12. März 2024 abgelöst. FID hat nur die Input-Verzögerung der ersten Interaktion gemessen. Wer bei INP scheitert, hat schweres JavaScript auf dem Main-Thread: Analytics-Skripte, die beim Klick 300 ms blockieren, React-Re-Renders, die Tausende Virtual-DOM-Nodes iterieren, Event-Handler in einer setTimeout(0)-Warteschlange, die nicht schnell genug abgearbeitet wird.

Cumulative Layout Shift (CLS): wie stabil das Layout bleibt

CLS erfasst unerwartete Layout-Shifts, also Sprünge von Elementen auf der Seite, wenn neuer Content nachgeladen wird. Jeder Shift trägt einen Score bei, basierend darauf, wie viel vom Viewport bewegt wurde und wie weit. Google summiert die Shifts innerhalb von Sitzungsfenstern (Shifts mit weniger als 1 Sekunde Abstand, jedes Fenster höchstens 5 Sekunden lang) und nimmt das größte Fenster als deinen CLS. Klicks und Taps innerhalb von 500 ms vor einem Shift zählen nicht (vom Nutzer ausgelöste Animationen sind also ok).

Guter CLS: 0,1 oder weniger. Schlecht: mehr als 0,25. Die üblichen Ursachen: Bilder ohne explizite width- und height-Attribute (der Browser reserviert keinen Platz, bis das Bild geladen ist, und schiebt dann den Content nach unten), dynamisch injizierte Werbung oder Embeds, Web-Fonts, die mitten im Paint umschwenken und den Textblock neu skalieren, und Hero-Sektionen mit einem spät ladenden Video, das den Artikel darunter nach unten drückt.

Die Grenzwerte für 2026

Google veröffentlicht drei Grenzwerte pro Metrik: Gut, Verbesserung nötig, Schlecht. Den Status „Gut“ bei einer Metrik erreichst du nur, wenn das 75. Perzentil deiner echten Nutzer in diesem Bereich liegt. Das bedeutet: 25 % deines Traffics können noch im „Schlecht“-Bereich sein und du bestehst trotzdem.

Eine Seite ist nur dann „gut auf Core Web Vitals“, wenn alle drei Metriken im 75. Perzentil gut sind. Eine einzige schlechte Metrik reicht, und du fällst durch. Im ganzen Web scheitern Seiten am häufigsten an LCP. Im CrUX-Release für August 2026 hatten 68,1 % der Origins einen guten LCP, gegenüber 81,5 % bei CLS und 85,3 % bei INP. INP wird allerdings schlechter, das Chrome-Team nennt die anhaltende Verschlechterung besorgniserregend.

Felddaten vs. Labordaten

Die größte Quelle der CWV-Verwirrung: Zwei Tools können dir für dieselbe Seite komplett unterschiedliche Antworten geben. Beide haben recht. Sie messen verschiedene Dinge.

Felddaten fassen die letzten 28 Tage echter Chrome-Nutzer auf deiner Seite zusammen. Google sammelt sie über den Chrome User Experience Report (CrUX), der anonymisierte Metriken von Nutzern sammelt, die zugestimmt haben. Felddaten sind das, was Google tatsächlich fürs Ranking verwendet. Du siehst sie oben im PageSpeed-Insights-Bericht, im Core-Web-Vitals-Bericht der Search Console und im rohen CrUX-BigQuery-Datensatz für seitenweite Analysen.

Labordaten sind ein einzelner simulierter Lauf auf einem gedrosselten Mobile-Profil. Lighthouse in den Chrome DevTools oder der PageSpeed-Insights-Laborlauf machen beide genau das. Das Profil: 1,6 Mbps Download, 750 Kbps Upload, 150 ms Round-Trip-Zeit, 4× CPU-Drosselung. Eine Näherung an ein Mid-Range-Smartphone auf 4G. Labordaten sind reproduzierbar: gleicher Input, gleiches Ergebnis. Deshalb erkennst du damit Regressionen vor dem Deploy. Aber kein einzelner echter Nutzer ist exakt auf diesem Profil unterwegs.

Wenn Feld und Labor auseinanderlaufen, sagt dir die Lücke etwas. In derselben DACH-Studie hatte br.de mobil im Labor einen LCP von 39,5 Sekunden, im Feld (CrUX-Origin-Daten, 75. Perzentil) dagegen 1,3 Sekunden. Die beiden Werte landen nicht einmal in derselben Kategorie: im Labor schlecht, im Feld gut. Warum, zeigt die Studie nicht. Ein häufiger Grund: Lighthouse lädt jede Seite kalt, echte Besucher kommen oft mit gefülltem Cache und bereits offenen Verbindungen. Das umgekehrte Muster, bei dem Labor besteht und Feld scheitert, bedeutet meistens, dass echte Nutzer langsame Geräte oder Ad-Blocker haben, die dein JavaScript brechen.

So misst du Core Web Vitals

Fünf Tools, jedes für eine andere Frage.

Was du nicht brauchst: einen RUM-Anbieter nur für CWV. web-vitals.js plus deine bestehende Analytics deckt ab, was die meisten Websites für CWV brauchen. Ein kommerzielles RUM-Produkt lohnt sich erst, wenn du zusätzlich Session-Replay oder Cross-Service-Tracing brauchst.

Beeinflussen Core Web Vitals das Google-Ranking?

Nur geringfügig. Google sagt, dass es die relevantesten Inhalte zuerst zeigt, auch wenn die Page Experience schlecht ist, und dass eine gute Page Experience helfen kann, wenn viele Seiten ähnlich hilfreich sind. Core Web Vitals fließen in die Ranking-Systeme ein, wiegen aber nicht schwerer als Relevanz. So beschreibt Google die Page Experience, seit es Core Web Vitals 2021 als Signal eingeführt hat.

Warum du dich trotzdem um CWV kümmern solltest, liegt nicht an Rankings, sondern an den Nutzern, die du schon hast. Eine Seite mit 5-Sekunden-LCP verliert echte Nutzer, bevor sie den Content sehen. Eine Seite mit 500 ms INP fühlt sich bei jedem Klick kaputt an. Eine Seite mit CLS 0,3 wirft Nutzer mitten im Lesen raus, wenn das Layout springt. Das sind Conversion-Probleme und Retention-Probleme. Der Ranking-Bonus ist ein Rundungsfehler neben dem UX-Verlust.

Google veröffentlicht nicht, wie stark Core Web Vitals gewichtet werden, und auch die Hinweise zur Page Experience sagen nicht, dass sie bei umkämpften SERPs mehr zählen. Ist eine Seite nicht relevant genug, ändert ein bestandener CWV-Test daran nichts.

LCP, INP und CLS optimieren

Vergiss den allgemeinen Rat „Mach die Seite schneller“. Was hilft, hängt davon ab, welche Metrik scheitert.

LCP fixen: das größte Element zuerst ausliefern

Identifiziere zuerst das LCP-Element. PageSpeed Insights sagt dir das im Diagnostik-Abschnitt. Suche nach „Largest Contentful Paint element“ mit dem exakten HTML. Es ist meistens ein Hero-Bild, eine Überschrift oder ein großer Textblock. Sobald du weißt, welches es ist, helfen diese Maßnahmen:

• Das LCP-Bild preloaden. <link rel="preload" as="image" href="..." fetchpriority="high"> im Head ergänzen. Das startet den Fetch, bevor der Browser den <img>-Tag beim Parsen entdeckt. Nur ergänzen, wenn du verifiziert hast, dass das Element wirklich der LCP ist, denn das falsche Bild zu preloaden verlangsamt den echten LCP (siehe Luminas eigene LCP-Untersuchung der Startseite vom 20.04.2026).
• Das LCP-Bild in WebP oder AVIF ausliefern. WebP spart 25–35 % gegenüber JPG bei gleicher Qualität. AVIF nochmal 20 % obendrauf. Beide werden 2026 von jedem Browser unterstützt. Cloudflare Images, ImageKit, Next.js Image oder ein Build-Time-Konvertierungsscript deckt das ab.
• loading="eager" und fetchpriority="high" auf dem LCP-Bild setzen. In manchen CMS ist loading="lazy" der Default, was above-the-fold den Fetch um hunderte Millisekunden verzögert. Eager + High Priority signalisieren den kritischen Pfad.
• Die Server-TTFB fixen. Jede Millisekunde TTFB geht direkt in den LCP ein. Am Edge cachen (Cloudflare, Fastly, Netlify). Wenn dein App-Server 800 ms zum Rendern braucht, rettet keine Front-End-Optimierung diese Zeit.
• Kritisches CSS inline stellen. Externe Stylesheets blockieren den First Paint. Zieh das CSS, das für den sichtbaren Bereich nötig ist, direkt in den Head und lade den Rest verzögert mit <link rel="preload" as="style" onload="this.rel='stylesheet'">.

INP fixen: den Main-Thread frei halten

INP scheitert, wenn JavaScript den Main-Thread während einer Nutzer-Interaktion blockiert. Alles dreht sich darum, lange Tasks zu verkürzen:

• Lange Tasks aufbrechen. Jeder synchrone JavaScript-Block, der länger als 50 ms läuft, ist in Chromes Vokabular ein „Long Task“. Teil ihn mit scheduler.yield() (modern) oder await new Promise(r => setTimeout(r, 0)) (kompatibel) innerhalb von Loops.
• Nicht essenzielle Third-Party-Skripte verzögert laden. Analytics, Chat-Widgets, Ad-Scripts, Heatmap-Tracker. Lade sie nach der ersten Interaktion, nicht beim Pageload. Luminas eigenes GTM-Setup nutzt Interaction-only-Deferral (Scroll, Klick, Keydown, Mousemove), um gtag.js aus dem Pre-Interaction-Main-Thread rauszuhalten.
• Forced Layout in Event-Handlern vermeiden. Das Lesen von offsetWidth, getBoundingClientRect, clientHeight direkt nach einem DOM-Write zwingt den Browser zu einer synchronen Layout-Neuberechnung. Bündel Lesezugriffe vor Schreibzugriffen und nutze requestAnimationFrame, wenn du Layout-Daten brauchst.
• CSS-Transitions statt JavaScript-Animationen. Transitions auf transform und opacity können auf dem Compositor-Thread laufen, JavaScript-Animationen laufen auf dem Main-Thread. INP misst die Verzögerung bis zum nächsten Paint, also halte den Klick-Handler selbst kurz und überlass die Optik dem CSS.
• React-Re-Renders reduzieren. React-Components, die bei jeder Interaktion re-rendern, besonders Context-Provider mit häufig wechselndem State, kaskadieren in hunderte Virtual-DOM-Diffs. Nutze React.memo, Refs für State ohne UI-Bezug und teil den Context nach Update-Häufigkeit auf.

CLS fixen: Platz reservieren, bevor Content ankommt

Die Liste für CLS ist kurz, wird aber oft ignoriert:

• Immer width und height auf jedem <img> setzen. Der Browser reserviert Platz über das Seitenverhältnis, bevor das Bild geladen ist. Ohne diese Attribute wird das Bild mit Null-Höhe eingefügt und schiebt danach alles nach unten.
• Platz für Werbung, Embeds und dynamisch injizierten Content reservieren. Umschließe den Slot mit einem <div> mit fester min-height, die zur erwarteten Content-Größe passt. Wenn die Werbung lädt, füllt sie den reservierten Platz, statt den Artikel zu schieben.
• font-display: swap vorsichtig einsetzen. Es verhindert unsichtbaren Text, triggert aber einen Layout-Shift, wenn die Web-Font lädt und die Fallback-Font ersetzt. Wenn Fallback und Web-Font ähnliche Metriken haben (size-adjust, ascent-override, descent-override auf dem @font-face), ist der Swap unsichtbar. Wenn nicht, bricht der Text neu um.
• Nach dem Laden keinen Content über bestehendem Content einfügen. Banner-Notifications, Cookie-Prompts, Newsletter-Overlays. Wenn sie mitten im Laden oben auf der Seite erscheinen, schieben sie alles nach unten. Rendere sie stattdessen als Fixed-Position-Overlays.

Nach den Fixes mit Luminas PageSpeed-Tool verifizieren (Feld + Labor in einem Bericht), JS vs. No-JS laufen lassen, um zu sehen, wie stark die CWV von deinem JavaScript-Layer abhängen, und im Alt Text Checker fehlende Bildmaße abfangen, die CLS verursachen. Alle drei kostenlos, ohne Login.

FAQ

Wo du anfängst

Fünf Schritte in Reihenfolge. 30 Minuten Baseline für eine kleine Seite, ein halber Tag für eine mittlere: