Drei Metriken, ein Ziel: Core Web Vitals messen Ladegeschwindigkeit (LCP ≤ 2,5 s), Reaktionsfähigkeit (INP ≤ 200 ms) und visuelle Stabilität (CLS ≤ 0,1) — und sind ein bestätigtes Page-Experience-Signal mit Rankingrelevanz.
INP ist der neue Engpass: Seit März 2024 ersetzt Interaction to Next Paint den alten FID-Wert und misst jede Interaktion auf der Seite — nicht nur die erste.
Field Data entscheidet: Für die offizielle CWV-Bewertung zählen Felddaten aus dem Chrome UX Report (CrUX) am 75. Perzentil. Lighthouse ist für die Diagnose da, nicht für die offizielle Bewertung. Optimiere für deine echten Besucher, nicht für einen Simulator.
Laut dem Web Almanac 2025 bestehen nur rund 48 % aller mobilen Websites alle drei Core Web Vitals. Das bedeutet: Mehr als die Hälfte des mobilen Webs liefert eine Nutzererfahrung, die Google als verbesserungswürdig oder schlecht einstuft. Und genau hier liegt deine Chance.
In meiner Arbeit als Product Developer bei iGaming.com und in technischen SEO-Audits für Kundenprojekte bei SEO Kreativ ist die Performance-Optimierung ein Dauerbrenner. Ich sehe noch regelmäßig Websites, die ein perfektes Lighthouse-Ergebnis feiern — und trotzdem rote Werte in der Search Console zeigen. Der Grund: Sie optimieren für den falschen Datensatz.
In meinem Pillar-Artikel über SEO für KI-Suche habe ich Core Web Vitals als eines der technischen Fundamente beschrieben — insbesondere den INP-Schwellenwert von 200 ms. Dieser Spoke-Artikel geht jetzt in die Tiefe — eingebettet in die Hub-and-Spoke-Architektur, die ich für seo-kreativ.de nutze: Was genau steckt hinter LCP, INP und CLS? Wie misst du sie richtig? Und wie optimierst du gezielt, ohne in einen Rabbit Hole aus Micro-Optimierungen abzurutschen?
Keine generischen Ratschläge, kein Tool-Overload. Stattdessen: ein strukturierter Workflow, der sich in der Praxis bewährt hat.
Was sind Core Web Vitals?
Core Web Vitals sind kein abstraktes Konzept. Es sind drei konkrete, messbare Kennzahlen, die Google seit 2021 in den Page-Experience-Kontext eingebettet und als Ranking-Signal kommuniziert hat. Jede Metrik deckt einen anderen Aspekt der Nutzererfahrung ab:
| Metrik | Misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP | Ladeleistung | ≤ 2,5 s | 2,5–4 s | > 4 s |
| INP | Reaktionsfähigkeit | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | Visuelle Stabilität | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Entscheidend: Die Core Web Vitals werden auf Basis des 75. Perzentils echter Felddaten bewertet. Das heißt, 75 % deiner Seitenaufrufe müssen den „Gut“-Schwellenwert erreichen, damit eine Seite als bestanden gilt. Ein paar schnelle Ladezeiten am Desktop reichen also nicht — was zählt, ist die Erfahrung deiner realen Besucher auf realen Geräten.
LCP: Largest Contentful Paint — Die Ladegeschwindigkeit
Der Largest Contentful Paint ist die Metrik, die am engsten mit dem subjektiven „die Seite ist da“-Gefühl verbunden ist. Er misst den Zeitpunkt, an dem das größte sichtbare Element im Viewport vollständig gerendert wurde. Das kann ein Hero-Bild sein, ein großer Textblock oder ein Video-Poster.
In meinen Kundenprojekten bei SEO Kreativ ist LCP fast immer der erste Hebel, den ich anfasse. Die häufigsten Bremsen, die ich in technischen Audits sehe:
Unoptimierte Hero-Bilder: Ein 2 MB großes JPEG im Header ist nach wie vor der Klassiker. Teurer Klassiker. Die Lösung: Bilder in WebP oder AVIF ausliefern, responsive Größen via srcset definieren und das LCP-Bild mit fetchpriority="high" priorisieren.
Lazy Loading am falschen Ort: Lazy Loading ist großartig — für Bilder unterhalb des sichtbaren Bereichs. Für das Hero-Bild oben ist es Gift. Der Browser verzögert damit genau das Element, das er zuerst laden soll. loading="lazy" hat am LCP-Element nichts verloren.
Langsame Serverantwort (TTFB): Time to First Byte ist die Basis. Wenn dein Server 800 ms braucht, bevor er überhaupt antwortet, kann kein Bild-Preload der Welt deinen LCP retten. Ein CDN, Server-seitiges Caching und optimierte Datenbankabfragen sind hier Pflicht — und helfen nebenbei auch deinem Crawl Budget.
Render-blockierende Ressourcen: Großes CSS und synchrones JavaScript im <head> blockieren den Rendering-Prozess. Critical CSS inline, den Rest asynchron nachladen, JavaScript mit defer oder async einbinden.
<link rel="preload" as="image" href="hero.webp" fetchpriority="high"> im <head>, um dem Browser explizit zu sagen: „Dieses Bild ist kritisch — lade es sofort.“ Das ist nach aktuellem Kenntnisstand eine der effektivsten einzelnen LCP-Optimierungen.INP: Interaction to Next Paint — Die Reaktionsfähigkeit
Wenn LCP den ersten Eindruck misst, dann misst Interaction to Next Paint das laufende Erlebnis. INP erfasst die Zeit zwischen einer Nutzerinteraktion (Klick, Tap, Tastendruck) und dem nächsten visuellen Update des Browsers. INP basiert auf der langsamsten relevanten Interaktion während des gesamten Seitenbesuchs, mit zusätzlicher Outlier-Behandlung bei sehr vielen Interaktionen.
Das war kein Zufall, dass Google FID durch INP ersetzt hat. FID hatte einen blinden Fleck: Er maß nur die erste Interaktion. Eine Seite konnte bei FID perfekt abschneiden, obwohl jeder weitere Klick 800 ms Verzögerung hatte. INP schließt diese Lücke.
Aus meiner Arbeit in technischen SEO-Audits kann ich sagen: INP ist die Metrik, die Entwickler am meisten ins Schwitzen bringt. Die Ursachen liegen fast immer tief im JavaScript:
Die drei Phasen einer Interaktion: Jede INP-relevante Interaktion besteht aus dem Input Delay (Wartezeit, bis der Main Thread frei ist), der Processing Time (Ausführung der Event-Handler) und dem Presentation Delay (Layout-Neuberechnung und Paint). Alle drei Phasen zusammen ergeben den INP-Wert.
Long Tasks: Jede JavaScript-Aufgabe, die länger als 50 ms den Main Thread blockiert, ist ein Long Task. Während dieser Zeit kann der Browser nicht auf Nutzereingaben reagieren. Die Lösung: Große Aufgaben in kleinere Stücke aufbrechen — beispielsweise mit requestIdleCallback() oder der neueren scheduler.yield() API.
Third-Party-Scripts: Tracking-Pixel, Chat-Widgets, A/B-Testing-Tools, Social-Media-Embeds. Jedes dieser Scripts kämpft um Rechenzeit auf dem Main Thread. Ich sehe regelmäßig Seiten mit 15 oder mehr Third-Party-Scripts. Die ehrliche Frage lautet: Brauchst du wirklich alle davon auf jeder Seite?
CLS: Cumulative Layout Shift — Die visuelle Stabilität
Cumulative Layout Shift ist die Metrik, die jeder Nutzer kennt, ohne den Namen zu kennen: Du willst auf einen Button klicken, aber plötzlich rutscht alles nach unten, weil ein Bild oder eine Werbeanzeige nachgeladen wurde. Willkommen beim Layout Shift.
CLS unterscheidet sich fundamental von LCP und INP: Es ist kein Zeitwert in Millisekunden oder Sekunden. Der Score wird berechnet, indem die Fläche des verschobenen Elements mit der Distanz der Verschiebung multipliziert wird. Nur unerwartete Shifts zählen — wenn ein Nutzer auf einen Accordion-Button klickt und sich Content öffnet, ist das erwartetes Verhalten und fließt nicht in CLS ein.
Die klassischen CLS-Verursacher, die ich in meiner Praxis am häufigsten sehe:
Bilder und Videos ohne Dimensionen: Wenn du im HTML keine width und height Attribute angibst (oder kein CSS aspect-ratio nutzt), kann der Browser keinen Platz reservieren. Das Element lädt → alles verschiebt sich. Fix: Immer explizite Dimensionen setzen.
Web-Fonts mit Flash-Effekt: Der Browser zeigt zuerst den Fallback-Font, dann springt die Webfont rein — mit anderer Zeilenhöhe. Ergebnis: Text verschiebt sich. Nutze font-display: swap oder besser font-display: optional, und gleiche Fallback- und Webfont-Metriken via size-adjust an.
Dynamisch injizierte Inhalte: Cookie-Banner, die den Content nach unten schieben. Werbe-Slots ohne reservierte Höhe. Lazy-geladene Teaser-Listen. Die Lösung ist immer gleich: Platz reservieren, bevor der Inhalt geladen wird.
Core Web Vitals messen und auswerten
Der häufigste Fehler, den ich sehe: Teams optimieren wochenlang, bis Lighthouse 100/100 zeigt — und wundern sich, warum die Search Console weiterhin orangene oder rote Werte meldet. Der Grund ist die Unterscheidung zwischen Lab Data und Field Data.
Lab Data wird unter kontrollierten Bedingungen gemessen: simuliertes Gerät, simulierte Netzwerkgeschwindigkeit, ein einzelner Seitenaufruf. Lighthouse, WebPageTest und die Lab-Sektion in PageSpeed Insights liefern Lab Data. Es ist ideal, um Ursachen zu identifizieren — aber es sagt nichts über die Erfahrung deiner echten Nutzer aus.
Field Data stammt von echten Chrome-Nutzern und wird im Chrome UX Report (CrUX) aggregiert. Die Search Console, die Field-Data-Sektion in PageSpeed Insights und Tools wie DebugBear oder Treo greifen darauf zu. Field Data bildet die Realität ab: verschiedene Geräte, verschiedene Netzwerke, verschiedene Nutzungsmuster.
Die wichtigsten Mess-Tools im Überblick: Die Google Search Console zeigt den CWV-Report unter „User Experience“ — gruppiert nach Status und Metrik, basierend auf CrUX-Daten über ein rollendes 28-Tage-Fenster. PageSpeed Insights kombiniert Lab- und Field-Daten für einzelne URLs. Chrome DevTools eignet sich für die Profiling-Analyse von INP (Performance-Tab → Interaktionen aufzeichnen). Und die web-vitals JavaScript Library kannst du direkt in deine Seite einbinden, um eigene Real-User-Monitoring-Daten zu sammeln.
Die 3 Core Web Vitals Metriken im Überblick
Core Web Vitals und SEO: Wie stark ist der Ranking-Einfluss?
Lass uns ehrlich sein: Core Web Vitals allein katapultieren keine Seite auf Position 1. Google selbst hat bei der Einführung des Page-Experience-Updates betont, dass Relevanz, Content-Qualität und nachweisbares E-E-A-T weiterhin die primären Faktoren sind. Aber: In einem Umfeld, in dem Content-Qualität zwischen Wettbewerbern oft eng beieinanderliegt, wird Page Experience zum differenzierenden Signal.
Aus meiner Arbeit als Product Developer bei iGaming.com — einem Umfeld mit extremem Wettbewerb um Top-Positionen — sehe ich den Effekt konkret: Seiten mit durchgängig grünen CWV-Werten zeigen nach bisherigen Analysen stabilere Rankings und eine höhere Widerstandsfähigkeit gegen Core-Update-Schwankungen. Das ist kein kausaler Beweis, aber ein konsistentes Muster.
Was Google offiziell sagt: Die Ranking-Systeme berücksichtigen Core Web Vitals als Teil des Page-Experience-Signals. CWV sind dabei ein Element neben weiteren technischen Signalen. Die alte Page-Experience-Report-Ansicht in der Search Console wurde entfernt, aber die CWV-Bewertung bleibt aktiv.
Der vielleicht wichtigste Aspekt wird oft übersehen: Core Web Vitals wirken nicht nur über das Ranking. Schnellere, stabilere Seiten haben in der Regel niedrigere Bounce-Rates, höhere Verweildauern und bessere Conversion-Rates. Diese Nutzersignale wiederum fließen laut den Google-Ranking-Mechanismen als Feedback-Daten in die Bewertung ein. Und auch für die Auswahl als Quelle in Google AI Overviews ist eine technisch einwandfreie Seite eine Grundvoraussetzung. Performance optimieren heißt also nicht nur „für Google optimieren“ — es heißt, die reale Erfahrung deiner Nutzer zu verbessern.
Optimierung: Der richtige Workflow
Der Fehler, den ich in meiner Praxis am häufigsten sehe: Teams stürzen sich auf die Metrik mit dem schlechtesten Wert, ohne die Abhängigkeiten zu verstehen. TTFB ist die Basis für LCP. LCP bestimmt, wann der Nutzer die Seite als „geladen“ wahrnimmt. INP entscheidet, ob die Interaktion danach flüssig ist. CLS ist in der Regel am schnellsten zu beheben und liefert sofortige UX-Verbesserungen.
Schritt 1: Search Console als Ausgangspunkt. Öffne den Core-Web-Vitals-Report und filtere nach Mobilgeräten. Identifiziere, welche Metrik scheitert und welche URL-Gruppen betroffen sind. URL-Gruppen sind der Schlüssel — sie zeigen dir, welche Templates Probleme haben.
Schritt 2: Repräsentative URLs testen. Nimm pro betroffener URL-Gruppe eine repräsentative Seite und analysiere sie in PageSpeed Insights. Achte auf die Field-Data-Sektion (nicht Lab). Wenn Field Data vorhanden ist, zeigt es dir den realen INP, LCP und CLS.
Schritt 3: LCP-Element identifizieren. In PageSpeed Insights siehst du, welches Element als LCP erkannt wurde. Ist es ein Bild? Dann prüfe: Format, Größe, Preload, fetchpriority. Ist es Text? Dann prüfe: Font-Loading-Strategie, Critical CSS, TTFB.
Schritt 4: INP im DevTools profilen. Öffne Chrome DevTools → Performance-Tab → starte eine Aufzeichnung → interagiere mit der Seite → stoppe. Suche nach langen Tasks (> 50 ms) und identifiziere, welche Scripts den Main Thread blockieren.
Schritt 5: CLS visuell prüfen. Lade die Seite im Throttled-Modus (Slow 3G in DevTools) und beobachte, wo Elemente springen. Häufig reicht es, Bilddimensionen zu setzen und dynamische Inhalte mit festen Containerhöhen zu versehen.
Schritt 6: Validierung beobachten. CrUX nutzt ein gleitendes 28-Tage-Fenster — Verbesserungen werden also schrittweise sichtbar, nicht erst exakt nach 28 Tagen. Nutze den „Fehlerbehebung überprüfen“-Button in der Search Console, um den Validierungsprozess manuell anzustoßen. Bei Seiten mit höherem Traffic sind Effekte schneller erkennbar.
Häufig gestellte Fragen (FAQ)
Sind Core Web Vitals ein direkter Google-Rankingfaktor?
Ja. Core Web Vitals sind ein bestätigtes Page-Experience-Signal mit Rankingrelevanz. Allerdings sind sie kein dominanter Faktor — Content-Relevanz, -Qualität und E-E-A-T wiegen stärker. CWV wirken primär als Tiebreaker bei sonst vergleichbaren Seiten.
Was ist der Unterschied zwischen FID und INP?
First Input Delay (FID) maß nur die Verzögerung bei der allerersten Nutzerinteraktion. Interaction to Next Paint (INP) misst die Reaktionszeit auf alle Interaktionen während des gesamten Seitenbesuchs und basiert auf der langsamsten relevanten Interaktion. INP hat FID am 12. März 2024 als offizielle Core-Web-Vital-Metrik ersetzt, weil es ein realistischeres Bild der tatsächlichen Responsiveness liefert.
Warum zeigt Lighthouse andere Werte als die Search Console?
Lighthouse verwendet Lab Data — synthetische Tests unter kontrollierten Bedingungen auf einem simulierten Gerät. Die Search Console nutzt Field Data aus dem Chrome UX Report, also echte Nutzerdaten über ein 28-Tage-Fenster. Die Datenquellen sind grundverschieden. Für die offizielle CWV-Bewertung zählen Felddaten; Lab Data dient dem Debugging.
Wie lange dauert es, bis Verbesserungen in der Search Console sichtbar werden?
CrUX nutzt ein gleitendes 28-Tage-Fenster. Verbesserungen werden schrittweise sichtbar — nicht erst nach exakt 28 Tagen. Bei Seiten mit höherem Traffic kann der Effekt schneller erkennbar sein, da mehr Datenpunkte gesammelt werden.
Betreffen Core Web Vitals mobile und Desktop-Rankings gleich stark?
Google verwendet Mobile-First-Indexierung, weshalb die mobilen CWV-Werte primär für das Ranking herangezogen werden. Separate Desktop-Daten werden in der Search Console ebenfalls angezeigt, aber der Mobile-Report hat für die Suchbewertung die höhere Priorität. Da der Großteil des Web-Traffics inzwischen mobil stattfindet, sollte die mobile Optimierung im Fokus stehen.
Kann ich Core Web Vitals auch ohne Entwickler-Kenntnisse verbessern?
Teilweise. Bildkomprimierung (LCP), das Setzen von Bilddimensionen (CLS) und das Entfernen unnötiger Plugins oder Third-Party-Scripts sind oft ohne tiefe Entwickler-Kenntnisse möglich. Die INP-Optimierung erfordert in der Regel JavaScript-Know-how, da Long Tasks identifiziert und aufgebrochen werden müssen. Für WordPress-Nutzer können Performance-Plugins wie WP Rocket oder LiteSpeed Cache einen guten Einstieg bieten.
Fazit: Performance ist kein Projekt, sondern ein Prozess
Drei Metriken, drei Schwellenwerte, ein klares Ziel: eine Website, die schnell lädt (LCP ≤ 2,5 s), sofort reagiert (INP ≤ 200 ms) und visuell stabil bleibt (CLS ≤ 0,1). Klingt einfach — ist es in der Umsetzung oft nicht. Aber der Aufwand lohnt sich, weil du nicht nur für Google optimierst, sondern für die Menschen, die deine Website nutzen.
Mein Rat aus der Praxis: Starte mit dem Search-Console-Report. Identifiziere das größte Problem auf Template-Ebene. Fixe es. Warte die Validierung ab. Dann das nächste. Kein Big-Bang, kein Über-Nacht-Wunder — sondern systematische, iterative Verbesserung.
Und vergiss nicht: Core Web Vitals sind ein Teil des technischen SEO-Fundaments, das du brauchst, um in der neuen KI-Suche sichtbar zu bleiben. Wie ich in meinem Guide zu SEO, AIO, GEO und LLMO beschrieben habe: Eine blitzschnelle, technisch einwandfreie User Experience ist ein klares Qualitätssignal — für klassische Suchmaschinen und für die KI-Systeme, die darauf aufbauen.
