Wenn die Core Web Vitals im roten Bereich liegen, kostet das Sichtbarkeit und Conversions. Dieser Leitfaden zeigt, wie du LCP, INP und CLS gezielt verbesserst — mit den Schwellwerten, die zählen, den Tools, die im Alltag tragen, und vier Projekten, in denen wir die Werte messbar nach oben gebracht haben: von 88 % weniger Seitengröße bei August Weber bis zum Cookie-Banner, der sich als LCP-Killer entpuppte.
Warum Performance über deine Sichtbarkeit entscheidet
Im Februar 2026 hat Google dokumentiert, was technische SEOs schon länger wussten: Googlebot indexiert beim Crawlen für die Google-Suche nur die ersten 2 MB einer HTML-Datei. John Mueller bestätigte auf Bluesky, das sei keine Verhaltensänderung, sondern eine Dokumentationsklarstellung. Für die meisten Websites – deren HTML unter 100 KB liegt – kein Problem. Anders sieht es aus, wenn eine Website inline eingebettetes JavaScript, große SVG-Blöcke oder unkontrollierten Tracking-Code direkt im HTML trägt: Alles jenseits der 2-MB-Grenze existiert für Google schlicht nicht.
Das verändert die Perspektive auf Website-Performance grundlegend. Core Web Vitals (CWV) messen, wie sich eine Webseite für echte Nutzer anfühlt. Wenn Google die Seite auf HTML-Ebene unvollständig sieht, greifen alle nachgelagerten Optimierungen ins Leere. Performance ist Grundvoraussetzung dafür, dass Google eine Website korrekt versteht, bewertet und rankt.
Was sind Core Web Vitals?
Core Web Vitals sind drei definierte Performance-Metriken, die Google seit Juni 2021 als Rankingfaktoren im Page-Experience-Signal einsetzt. Sie messen Ladegeschwindigkeit, Interaktivität und visuelle Stabilität von Webseiten anhand konkreter Schwellwerte aus echten Nutzerdaten. Alle drei Web Vitals zusammen bilden Googles Page-Experience-Bewertung.
LCP – Largest Contentful Paint
Der Largest Contentful Paint (LCP) misst, wie lange es dauert, bis das größte sichtbare Element einer Website vollständig gerendert ist. Typischerweise ist das ein Hero-Bild, ein großer H1-Block oder ein dominantes Textelement above the fold. Die aktuellen Schwellwerte:
- Gut: unter 2,5 Sekunden
- Verbesserungswürdig: 2,5 bis 4 Sekunden
- Schlecht: über 4 Sekunden
Der Largest Contentful Paint reagiert auf mehrere Faktoren gleichzeitig: Server-Antwortzeit (TTFB), Render-Blocking durch CSS und JavaScript, Bildgröße und die Priorisierungslogik des Browsers. Darin liegt seine Tücke – ein einzelner Hebel reicht selten, um diese Metrik verlässlich ins Grüne zu bringen.
200+
5,0
zufriedene Kunden
INP – Interaction to Next Paint
Der Interaction to Next Paint (INP) ist seit dem 12. März 2024 ein Core Web Vital. Er hat den First Input Delay (FID) abgelöst – eine Entscheidung, die Google seit langem vorbereitet hatte. INP misst, wie schnell eine Website auf Nutzereingaben reagiert – und zwar nicht nur auf die erste, sondern auf alle Interaktionen während der gesamten Sitzung. Das macht INP deutlich strenger als FID.
- Gut: unter 200 Millisekunden
- Verbesserungswürdig: 200 bis 500 ms
- Schlecht: über 500 ms
INP erfasst den vollständigen Interaktionszyklus: Input Delay (Wartezeit bis zur Verarbeitung), Processing Time (JavaScript-Ausführung) und Presentation Delay (Zeit bis zum visuellen Feedback). Diese Metrik ist umfassender als der First Input Delay (FID), der nur die Verzögerung vor der allerersten Interaktion maß – und zu oft ein zu optimistisches Bild lieferte.
CLS – Cumulative Layout Shift
Der Cumulative Layout Shift (CLS) bewertet die visuelle Stabilität einer Website. Ein schlechter CLS bedeutet: Inhalte springen beim Laden. Ein hoher CLS-Wert bedeutet: Inhalte springen beim Laden. Wie stark verschiebt sich das Layout der Website während des Ladevorgangs? Ein Bild, das nachlädt und Inhalte nach unten drückt, oder ein Cookie-Banner, der beim Rendern alle anderen Elemente einer Website neu anordnet – das alles schlägt auf den CLS-Wert durch.
- Gut: unter 0,1
- Verbesserungswürdig: 0,1 bis 0,25
- Schlecht: über 0,25
Der Cumulative Layout Shift ist eine der am häufigsten unterschätzten Metriken. Nicht weil die Messung komplex wäre, sondern weil die Ursachen oft an unerwarteten Stellen liegen: Webfonts ohne Fallback, Bilder ohne Dimensionsattribute, dynamisch nachrückende Werbeflächen auf Seiten mit viel dynamischem Inhalt.
Warum FID durch INP ersetzt wurde
First Input Delay (FID) hatte ein strukturelles Problem: Er maß ausschließlich die Verzögerung vor der allerersten Interaktion auf einer Seite. Wenn der erste Klick schnell verarbeitet wurde, alle weiteren Interaktionen aber stockten, lieferte FID trotzdem eine gute Bewertung.
INP löst das, indem er alle Interaktionen über die gesamte Sitzung beobachtet und den schlechtesten Wert als repräsentativ wertet. Wer einen guten First Input Delay gewohnt war, stellte nach dem 12. März 2024 oft fest: Der INP-Score der gleichen Webseite fiel deutlich schlechter aus. Wer im Search Console Bericht noch First-Input-Delay-Werte sieht, arbeitet mit veralteten Daten. FID ist seither offiziell abgekündigt.
Wie wir Core Web Vitals in der Praxis verbessern
Vier Cases aus unserer eigenen Arbeit – mit Zahlen, wo sie vorliegen:
Case 1: Inline-SVG-Bloat auf jsh.marketing
Auf jsh.marketing hatten wir über längere Zeit SVG-Grafiken direkt inline im HTML eingebettet. Das bläht das HTML-Volumen jeder betroffenen Seite massiv auf. Nach dem Auslagern der SVGs in externe Dateien sank das unkomprimierte HTML-Volumen deutlich. TTFB verbesserte sich messbar, und der Browser konnte den Critical Render Path schneller identifizieren. Ergebnis: bessere Werte im Labor und – mit der typischen Verzögerung von 4 bis 6 Wochen – auch in den CrUX-Metriken.
Case 2: WP Rocket Used CSS
WP Rockets “Used CSS”-Feature generiert für jede URL der Website einen minimierten CSS-Block, der nur die auf dieser Seite tatsächlich verwendeten Regeln enthält. Statt 400 KB globalem Stylesheet bekommen Seiten nur ihren relevanten CSS-Anteil – das reduziert Render-Blocking erheblich und senkt die Total Blocking Time (TBT). Bei WordPress-Webseiten gehört das zu unseren Standardmaßnahmen im technischen SEO. Die Konfiguration erfordert Sorgfalt, zahlt sich für Ladezeit und Metriken zuverlässig aus.
Case 3: Cookie-Banner als LCP-Killer
Ein unterschätzter Performance-Faktor auf DACH-Websites: Cookie-Banner, die synchron geladen werden und vor dem Hero-Element rendern. Wenn der Browser den Banner als größtes sichtbares Element erkennt, misst er dessen Renderzeit als diesen Wert – technisch korrekt, aber inhaltlich irreführend. Lösung: Cookie-Banner asynchron laden und fetchpriority="high" auf dem Hero-Element setzen.
Case 4: August Weber – 88 % Seitengröße reduziert
Beim Mittelständler August Weber reduzierte ein gezielter SVG-Fix die Seitengröße um 88 %. Lighthouse-Score-Sprung: zweistellig. Ehrliche Einschätzung: CrUX-Metriken hinken Lighthouse-Verbesserungen erfahrungsgemäß 4 bis 6 Wochen hinterher – CrUX braucht neue Nutzersitzungen, bevor aktualisierte Werte erscheinen. Wer sofortige Ranking-Effekte erwartet, wird enttäuscht.
Schlechte Web Vitals – was jetzt?
LCP verbessern
Die wirkungsvollsten Hebel für den Largest Contentful Paint (LCP) auf Webseiten:
- TTFB senken – Server-Caching, besseres Hosting, CDN. Ohne soliden TTFB sind alle anderen Maßnahmen Symptomkosmetik.
- Hero-Element priorisieren –
fetchpriority="high"auf dem LCP-Element setzen. - Bildformate modernisieren – WebP oder AVIF statt JPEG/PNG, mit passender Bildgröße für mobile Viewports.
- Kritisches CSS inline – Render-Blocking für Above-the-Fold-Inhalte reduzieren.
- Drittanbieter-Skripte prüfen – Tag Manager, Chat-Widgets und Consent-Tools blockieren oft den Critical Path.
INP verbessern
INP-Probleme auf einer Website sind fast immer JavaScript-Probleme:
- Long Tasks aufbrechen – Funktionen über 50 ms auf dem Main Thread blockieren jede Interaktion. Mit
scheduler.postTask()aufteilen. - Event Handler entschlacken – Schwere Logik aus Click-Handlern herauslösen und asynchron ausführen.
- Third-Party-Skripte prüfen – Chat-Widgets, Pixel und Tag Manager sind häufige INP-Killer auf jeder DACH-Website – und waren es als First Input Delay-Problem schon vor dem Switch zu INP.
CLS stabilisieren
Die wichtigsten Hebel für einen guten CLS-Wert:
- Width und Height auf Images – Fehlende Dimensionsattribute sind der häufigste Auslöser für einen schlechten Cumulative Layout Shift.
font-display: optional– Verhindert Layout-Shifts durch nachgeladene Webfonts.- Platzhalter für dynamische Inhalte – Werbeflächen und dynamische Blöcke mit reservierten Höhen versehen.
Wie stark beeinflussen CWV das Ranking wirklich?
Ehrliche Einschätzung: Core Web Vitals sind ein Rankingfaktor mit Tiebreaker-Charakter. Google kommuniziert das konsistent – inhaltliche Relevanz hat Vorrang. Wenn zwei Seiten inhaltlich vergleichbar sind, kann die CWV-Bewertung den Ausschlag geben. Der stärkere Effekt läuft über UX: schnell ladende Seiten haben niedrigere Absprungraten und bessere Verweildauern – was sich indirekt auf Rankings auswirkt.
Wie Google Core Web Vitals wirklich bewertet
Field Data vs. Lab Data
Hier liegt einer der häufigsten Irrtümer in der Praxis: Lighthouse-Score und Ranking-Relevanz sind nicht dasselbe. Für die Page-Experience-Bewertung von Webseiten zählt Google ausschließlich Field Data – Metriken echter Nutzer, gesammelt über den Chrome User Experience Report (CrUX). Lighthouse liefert Laborwerte unter kontrollierten Bedingungen, die für Diagnose und Entwicklung wertvoll sind, das Ranking aber nicht bestimmen.
CrUX ist die einzige Datenquelle für die CWV-Bewertung. Ein Lighthouse-Score von 92 auf einer Seite kann problemlos mit einem CrUX-Wert im “Verbesserungswürdig”-Bereich zusammenfallen. Das ist die Zahl, die zählt. Felddaten spiegeln, was Nutzer wirklich erleben.
Die 75th-Percentile-Logik
Google bewertet keine Durchschnittswerte, sondern das 75. Perzentil (p75). Mindestens 75 % aller Nutzersitzungen auf einer Seite müssen den Gut-Schwellwert der jeweiligen Metrik erreichen, damit die Seite als “gut” eingestuft wird. Die schnellsten 25 % werden beim Ergebnis nicht berücksichtigt – die schlechtesten 25 % aber voll. Für Websites mit heterogenem Publikum, etwa Seiten mit vielen mobilen Nutzern in Regionen mit schwachem Netz, ist das eine reale Hürde.
URL-Gruppen und Origin-Level
CrUX arbeitet mit URL-Gruppen, nicht mit einzelnen URLs. Wenn für eine URL nicht genug Field Data vorliegen, greift Google auf ähnliche Seiten oder die Origin-Level-Daten der Domain zurück. Eine schlecht performende Kategorienseite zieht die CWV-Bewertung der gesamten Website nach unten..
Die richtigen Tools im Überblick
PageSpeed Insights
PageSpeed Insights ist das Standardtool für schnelle CWV-Checks auf einzelnen Seiten einer Website: kostenlos, zeigt Lab-Daten (Lighthouse-Score) und Field Data aus CrUX nebeneinander, getrennt nach Desktop und Mobilgeräten. Schwäche: nur eine URL pro Analyse, kein historisches Tracking über alle URLs einer Website. Für schnelle Einzeldiagnosen bleibt PSI das meistgenutzte dieser Tools im Alltag – und als Bericht für Kunden gut kommunizierbar.
Core Web Vitals Report in der Search Console
Der CWV-Bericht in der Google Search Console ist die einzige Quelle, die zeigt, wie Google die Seiten einer Website tatsächlich in die drei Kategorien einordnet: “Gut”, “Verbesserungswürdig” oder “Schlecht”. Die Metriken im Bericht basieren direkt auf CrUX. URL-Gruppen werden hier sichtbar, und für jede Gruppe zeigt der Bericht, welche konkreten URLs und Seiten betroffen sind. Wer den CWV-Status einer Website seriös tracken will, kommt an diesem Bericht nicht vorbei – er ist das entscheidende Tool.
CrUX Dashboard in Looker Studio
Das CrUX Dashboard (über Looker Studio) gibt Zugriff auf historische Field-Data-Berichte für eine gesamte Origin. So lassen sich Trends über Monate abbilden – zum Beispiel, ob eine Performance-Maßnahme auf bestimmten Seiten sich tatsächlich in den CrUX-Metriken niedergeschlagen hat. Der Vorteil gegenüber PageSpeed Insights: site-weite Perspektive auf alle Seiten statt Einzelseiten-Snapshot.
Lighthouse in Chrome DevTools
Lighthouse ist das Lab-Tool der Wahl für Entwickler: direkt im Browser, detaillierter Output zu Render-Blocking, Total Blocking Time (TBT), Time to Interactive (TTI) und Long Tasks auf einer Seite. Die Total Blocking Time ist besonders hilfreich, um JavaScript-Blockierungen zu lokalisieren, die INP beeinflussen. Für Entwicklung und Debugging unverzichtbar. Klar ist aber: Lighthouse-Scores korrelieren oft nicht mit dem, was der CrUX-Bericht ausweist. Das liegt daran, dass Lighthouse unter kontrollierten Bedingungen misst, CrUX aber echte Nutzer auf realen Geräten abbildet.
GTmetrix, WebPageTest und experte.de
GTmetrix und WebPageTest eignen sich für technische Deep-Dives: Wasserfall-Diagramme, Connection-Timing, Third-Party-Analysen. Nützlich, aber nicht ranking-relevant. Das Pagespeed-Tool von experte.de ist praktisch für Bulk-Checks über viele Seiten – kein Ersatz für PageSpeed Insights oder Search Console.
Core Web Vitals und Pagespeed: Was der Unterschied ist
Pagespeed ist breiter – Core Web Vitals sind präziser
“Pagespeed” ist ein Sammelbegriff für alles rund um Ladezeit und Ladegeschwindigkeit. Core Web Vitals sind ein klar abgegrenztes Subset: drei spezifische Metriken mit definierten Schwellwerten. Ein hoher Page Speed Score allein sagt wenig aus – entscheidend sind die drei CWV-Metriken in den Field-Data-Berichten.
TTFB als Wurzel vieler LCP-Probleme
Time to First Byte (TTFB) ist kein eigenständiger Core Web Vital, aber oft die eigentliche Ursache für schlechte LCP-Werte auf Webseiten. Wenn der Server bereits 1,5 Sekunden für die erste Antwort braucht, ist das Laden-Ziel von 2,5 Sekunden rechnerisch kaum erreichbar – egal wie optimiert das Frontend der Website ist. Im Diagnose-Prozess beginnt eine solide CWV-Arbeit deshalb immer mit dem TTFB, bevor Bilder, CSS oder JavaScript auf Seiten angefasst werden.
Mobile-First: Google misst primär auf dem Smartphone
Google zieht für die CWV-Bewertung primär mobile Field Data heran. Desktop-Werte sind sekundär. Das ist für viele Mittelstandswebsites unbequem: Die interne Qualitätskontrolle läuft oft auf dem Desktop, wo Lighthouse-Scores glänzen – während mobile Nutzer ganz andere Erfahrungen machen. Mobile Ladegeschwindigkeit ist Teil der CWV-Grunddiagnose.
Was der 2-MB-HTML-Limit konkret bedeutet
Zurück zum Ausgangspunkt: Googlebot indexiert nur die ersten 2 MB einer HTML-Datei pro Seite. CSS- und JavaScript-Dateien werden separat gefetcht – jede einzelne Ressource unterliegt dabei ebenfalls dem 2-MB-Limit. Inline eingebetteter Code zählt zum HTML-Volumen der Seite; extern verlinkte Ressourcen werden einzeln bewertet. Massiv aufgeblähtes HTML – etwa durch Inline-SVGs, JSON-Datenblöcke oder ungekürzte Skripte direkt im Body – kann dazu führen, dass Seiteninhalte jenseits der 2-MB-Marke für Google unsichtbar werden, ohne dass Search Console einen Fehler meldet.
Core Web Vitals im SEO-Audit
Im SEO-Audit ist die CWV-Diagnose immer der erste Block. Nicht weil die Metriken das Ranking dominieren, sondern weil schlechte Performance einer Website die unsichtbare Decke ist, die alle anderen Maßnahmen wirkungslos macht: hervorragend optimierte Inhalte auf Seiten, die wegen aufgeblähtem HTML nicht vollständig indexiert werden – oder Conversion-Seiten, deren mobile Ladegeschwindigkeit Nutzer vor dem Klick verliert.
Das verbindet Web Vitals direkt mit dem technischen Fundament einer Website. Besonders nach einem Relaunch ist ein CWV-Check Pflicht: Template-Wechsel und CMS-Migrationen setzen Metriken häufig zurück, die vorher im grünen Bereich lagen. Für WordPress-Websites gibt es strukturierte Ansätze aus Plugin-Kombination, Used-CSS-Konfiguration und serverseitigem Caching, die im Rahmen von SEO-Webdesign-Projekten sauber umgesetzt werden können.
Wenn du wissen willst, wo deine Website und ihre Seiten in dieser Diagnose stehen – meld dich für ein Strategiegespräch.
