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

Jeder SEO-Blog hat einen Core-Web-Vitals-Artikel. Keiner davon besteht die Core Web Vitals selbst. Ich habe Luminas PageSpeed-Tool gegen 10 vielzitierte CWV- und Pagespeed-Artikel aus den Google-Top-Ergebnissen EN und DE laufen lassen. In den Felddaten (also dem, was Google tatsächlich fürs Ranking verwendet) zeigt keine der fünf englischsprachigen Seiten den Status „Gut“ bei CWV. Ahrefs, das Top-SEO-Ergebnis, holt einen Labor-PSI im hohen 70er-Bereich, liefert aber eine reale INP-Zeit von 390 Millisekunden, fast doppelt so hoch wie der 200-ms-Grenzwert. Moz rankt für page speed auf Seite 1 mit einem mobilen PSI um 17, die Feld-INP liegt bei 477 ms. Backlinkos Leitfaden ist 373 Tage alt und verfehlt „Gut“ bei INP mit 248 ms, knapp über dem 200-ms-Grenzwert.

Core Web Vitals sind drei Kennzahlen, mit denen Google bewertet, wie sich eine Seite für einen echten Nutzer anfühlt. Largest Contentful Paint (LCP) misst, wann der Hauptinhalt erscheint. Interaction to Next Paint (INP) misst, wie schnell die Seite auf Klicks und Taps reagiert. Cumulative Layout Shift (CLS) misst, wie stabil das Layout beim Laden bleibt. Die Werte kommen aus Chrome-Felddaten echter Nutzer, also 28-Tage-Rolling-Durchschnitte, nicht aus einer Laborsimulation auf einer einzelnen Maschine.

Dieser Leitfaden ist die komplette Evergreen-Referenz zu Core Web Vitals im Jahr 2026. Die drei Metriken mit konkreten 2026er-Grenzwerten, warum dein PSI-Score und dein Search-Console-Bericht selten übereinstimmen, die fünf Tools, die CWV korrekt messen, die knappe Antwort auf die Ranking-Frage und ein konkreter Taktik-Katalog für jede der Metriken LCP, INP und CLS. Die Daten im Live-Audit unten stammen aus erster Hand: Luminas PageSpeed-Tool hat am 22.04.2026 PSI-Probes und /deep-Schema-Fetches gegen alle 10 Wettbewerber ausgeführt.

Was Core Web Vitals wirklich messen

Drei Metriken, jede mit einer klaren Aufgabe. Zusammen beantworten sie die Frage „fühlt sich diese Seite auf einem echten Gerät für einen echten Nutzer schnell an?“. Besser, als es eine einzelne Zahl jemals konnte.

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 Frame, in dem der Nutzer zum ersten Mal das Gefühl hat: „Ok, die Seite ist da.“ Die Stoppuhr startet bei der Navigation und endet bei diesem einen Paint. Alles danach zählt nicht mehr.

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. In Luminas CWV-Audit erreicht Moz einen Labor-LCP von 22–27 Sekunden (Run-zu-Run-Varianz, beide katastrophal) wegen eines render-blockierenden Cookie-Banners und eines übergroßen Hero-Bilds. Dynatrace kommt auf 28,7 Sekunden, weil ihr Docs-Framework jedes Bild lazy-loadet, inklusive des above-the-fold.

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 den vollen Round-Trip 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. Google nimmt das 98. Perzentil über alle Interaktionen auf der Seite. Ein einzelner langsamer Klick ruiniert also den Score, eine Handvoll normaler Klicks aber nicht.

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 und war leicht zu manipulieren. INP erfasst die volle Interaktions-Latenz über jeden Interaktionstyp. Die Seiten, die bei INP scheitern, laufen mit schwerem JavaScript auf dem Main-Thread, also Analytics-Skripte, die beim Klick 300 ms blockieren, React-Re-Renders, die Tausende Virtual-DOM-Nodes iterieren, Event-Handler in einer setTimeout(0)-Queue, die nicht schnell genug abgearbeitet wird. Ahrefs hat in Luminas Audit einen Feld-INP von 390 ms. Moz schafft 477 ms.

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 Session-Windows (5-Sekunden-Lücken) und nimmt das größte Window 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 Google-Developer-Docs scheitern im Lumina-Audit selbst bei CLS mit 0,16 im Feld. Ein Freshness-Banner verschiebt das Layout nach dem initialen Paint.

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. Google optimiert auf die mittlere bis durchschnittliche Erfahrung, nicht auf den Best Case.

Eine Seite ist nur dann „gut auf Core Web Vitals“, wenn alle drei Metriken im 75. Perzentil gut sind. Eine einzige schlechte Metrik kippt dich raus. Die meisten Seiten, die CWV verfehlen, scheitern an genau einer Metrik, im Jahr 2026 meistens an INP, weil JavaScript weiter wächst, Server-Rendering aber schneller geworden ist. Backlinko ist ein sauberes Beispiel: LCP im Feld 1,9 s (gut), CLS 0,00 (gut), INP 248 ms (Verbesserung nötig). Knapp dran, aber nicht bestanden.

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 sind die 28-Tage-Rolling-Aggregate echter Chrome-Nutzer auf deiner Seite. 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. Felddaten sind die Wahrheit darüber, wie deine Nutzer die Seite wirklich erleben.

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. So erkennst du Regressionen vor dem Deploy, debuggst eine bestimmte Metrik und profilest Änderungen. Aber kein einzelner echter Nutzer ist exakt auf diesem Profil unterwegs.

Wenn Feld und Labor auseinanderlaufen, sagt dir die Lücke etwas. Ahrefs hat im Lumina-Audit einen Feld-LCP von 2,1 s (gut), aber einen Labor-LCP im Bereich 4–5 s. Das heißt: Chromes Produktionsnutzer rendern den ersten Paint schneller als die gedrosselte Lab-Simulation, vermutlich weil Ahrefs aggressive Preconnects und CDN-Caching ausliefert, von denen echte Browser profitieren, während Lighthouse immer kalt läuft. 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 mit einem Job. Welches du nimmst, hängt davon ab, was du beantworten willst.

Was du nicht brauchst: Third-Party-RUM-Vendors allein für CWV. web-vitals.js plus deine bestehende Analytics deckt 95 % dessen ab, was Paid-Tools anbieten. Kaufe ein kommerzielles RUM-Produkt nur, wenn du User-Session-Replay oder Cross-Service-Tracing zusätzlich zu CWV brauchst — nicht für CWV allein.

Beeinflussen Core Web Vitals das Google-Ranking?

Nur geringfügig. Google nennt Page Experience einen „Tiebreaker“ zwischen Seiten ähnlicher Qualität. Ein Ranking-Signal, ja, aber ein kleines. Content-Qualität und Backlinks dominieren die SERP 2026 wie 2021, als Google CWV als Signal eingeführt hat.

Den Beweis gegen CWV als starken Ranking-Faktor liefert die SERP selbst. Moz rankt auf Seite 1 für page speed mit einem mobilen PSI-Score um 17, eine Seite, die bei LCP und INP in den Chrome-Felddaten Good verfehlt. Ahrefs rankt #9 für core web vitals, obwohl sie INP um Faktor zwei verfehlen. Das sind keine Sonderfälle. Wenn CWV ein starker Ranking-Faktor wäre, würden Seiten, die CWV katastrophal verfehlen, nicht in den Top 10 für CWV-nahe Keywords sitzen. Tun sie aber. Regelmäßig.

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.

Eine Einschränkung beim „marginalen Ranking“-Punkt: Google gewichtet CWV im Page-Experience-Signal stärker bei umkämpften SERPs mit vergleichbarer Content-Qualität. In einem engen Rennen zwischen zwei Seiten auf gleichem thematischem Niveau und gleicher Autorität gewinnt die, die CWV besteht. Wenn du bereits auf #1 stehst, ist CWV Kosmetik. Wenn du auf #4 gegen drei gleichwertige Seiten kämpfst, ist das genau der Tiebreaker.

LCP, INP und CLS optimieren

Jede Metrik hat eigene Failure-Modi und einen eigenen Fix-Katalog. Lass den allgemeinen „Mach die Seite schneller“-Ratschlag weg; die spezifische Taktik 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, was es ist, ist der Fix-Katalog:

• 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. Spart auf den meisten Seiten 100–400 ms. 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 Homepage-LCP-Investigation vom 20.04.2026 für das Muster).
• 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. Extrahiere das CSS, das für above-the-fold nötig ist, und inlinee es im Head. Defere den Rest 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. Der Fix-Katalog dreht sich ausschließlich 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“. Splitte ihn mit scheduler.yield() (modern) oder await new Promise(r => setTimeout(r, 0)) (kompatibel) innerhalb von Loops.
• Nicht essentielle Third-Party-Skripte defern. 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. Batch Reads vor Writes; nutze requestAnimationFrame, wenn du Layout-Daten brauchst.
• CSS-Transitions statt JavaScript-Animationen. CSS läuft auf dem Compositor-Thread, JS-Animationen auf dem Main-Thread. Ein Dropdown mit transition: opacity 0.2s reagiert in 16 ms; dasselbe Dropdown mit einem 200-Zeilen-JS-Handler braucht auf langsamen Geräten 200 ms+.
• 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. Memoize mit React.memo, nutze Refs für Non-UI-State, splitte Context nach Update-Frequenz.

CLS fixen: Platz reservieren, bevor Content ankommt

CLS ist fixbar mit konsequenter Aufmerksamkeit auf Layout-Stabilität. Der Fix-Katalog 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, reflowt der Text.
• Keinen Content über bestehenden Content einfügen nach dem Load. 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: