Core Web Vitals sind seit 2021 offizielle Google-Ranking-Faktoren. LCP, INP und CLS messen die reale Nutzererfahrung Ihrer Website. Wer hier schlecht abschneidet, verliert Rankings — egal wie gut der Content ist.
Core Web Vitals sind drei von Google definierte Metriken zur Messung der realen Nutzererfahrung (Page Experience) einer Website: Ladegeschwindigkeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS). Sie sind seit dem Page Experience Update 2021 offizielle Ranking-Signale.
Misst: Wie lange es dauert, bis das größte sichtbare Element (Bild, Text) geladen ist.
Schwellenwerte:
Hauptursachen: Langsame Server, große Bilder, blockierendes JavaScript/CSS, keine CDN.
Misst: Reaktionszeit der Seite auf Nutzerinteraktionen (Klicks, Tippen, Tastatureingaben). Seit März 2024 ersetzt INP den alten FID-Wert.
Schwellenwerte:
Hauptursachen: Schweres JavaScript, lange Tasks, ineffizienter Event-Handler-Code.
Misst: Visuelle Stabilität — wie sehr sich Seitenelemente während des Ladens unerwartet verschieben.
Schwellenwerte:
Hauptursachen: Bilder ohne Dimensionen, dynamisch eingefügte Inhalte, Web-Fonts ohne Fallback.
Google klassifiziert jede Metrik in drei Stufen. Die kritische Linie ist „Good" – nur Pages, bei denen 75 % der Real-User diesen Wert erreichen, gelten als Page-Experience-positiv.
| Metrik | Was wird gemessen | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP | Ladezeit des größten sichtbaren Inhalts | ≤ 2,5 s | 2,5 – 4,0 s | > 4,0 s |
| INP | Reaktionszeit auf Nutzer-Interaktionen | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS | Summe unerwarteter Layout-Verschiebungen | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
| FCP | First Contentful Paint (ergänzend, nicht CWV) | ≤ 1,8 s | 1,8 – 3,0 s | > 3,0 s |
| TTFB | Time to First Byte (Server-Response) | ≤ 800 ms | 800 ms – 1,8 s | > 1,8 s |
Quelle: Google web.dev (Stand 2026). Werte gelten für mobile Endgeräte; Desktop-Schwellwerte sind teilweise strenger.
Diese sieben Anti-Patterns sehen wir in über 80 % aller Audits. Wer sie systematisch beseitigt, holt im Schnitt 30 – 50 % Verbesserung pro Metrik.
width- und height-Attribute setzen, Aspect-Ratio per CSS sichern.
font-display:swap oder optional + Preload kritischer Fonts.
defer oder async setzen, Cookie-Banner via CMP-Tag-Manager spät einbinden, Tracker bündeln.
srcset für responsive Bilder, loading="eager" und fetchpriority="high" nur für das LCP-Element.
loading="lazy" gesetzt ist, lädt es zu spät — LCP explodiert. Lösung: Lazy-Loading nur unterhalb des sichtbaren Bereichs nutzen.
requestIdleCallback für nicht-kritische Tasks, Web Workers für rechenintensive Operationen.
min-height, Skeleton-Placeholder, CMP mit Layout-Reserve.
Die folgenden fünf Code-Snippets adressieren die häufigsten Core-Web-Vitals-Probleme. In den meisten Setups direkt einsetzbar.
Im <head> einer Page mit großem Hero-Bild:
Browser reserviert Platz vor dem Bild-Download:
Im <head>:
Im CSS (verhindert FOIT/FOUT):
Nicht-kritisches JS am Ende der Page oder im <head> mit defer:
Container mit fester aspect-ratio vor dem Embed:
INP bewertet die langsamste Interaktion eines Seitenbesuchs — ein einziger träger Klick reicht, um die gesamte Seite in den gelben oder roten Bereich zu ziehen. In der Praxis stecken hinter schlechten INP-Werten fast immer dieselben vier Ursachen:
Das wirksamste Muster: sichtbare Rückmeldung sofort rendern, alles Unkritische erst danach ausführen. So bleibt die gefühlte Reaktionszeit unter 200 ms:
In Browsern ohne scheduler.yield() leistet setTimeout(fn, 0) denselben Dienst. Welche Interaktion konkret bremst, zeigt der INP-Eintrag im Performance-Panel der Chrome DevTools.
Layout-Verschiebungen lassen sich systematisch beseitigen — wichtig ist die Reihenfolge: erst den Verursacher identifizieren, dann gezielt Platz reservieren. So gehen Sie vor:
width- und height-Attribute im HTML setzen, damit der Browser den Platz vor dem Download reserviert.min-height oder aspect-ratio.font-display:swap setzen und das Hauptgewicht per Preload laden, damit Text nicht nachträglich umbricht.transform animieren: Animationen über top, left oder margin verschieben umliegende Elemente und zählen in den CLS-Wert.Die Schritte 2 und 3 beseitigen in den meisten Projekten bereits den Großteil des CLS-Werts:
Nach jedem Schritt neu messen: In Lab-Daten wirken CLS-Korrekturen sofort, die Field-Daten im Chrome User Experience Report ziehen wegen des 28-Tage-Fensters zeitverzögert nach.
Beispiel aus einem unserer Kunden-Audits — Mittelstands-Website mit klassischen Performance-Problemen. Maßnahmen über 6 Wochen, Field-Daten aus dem Chrome User Experience Report.
preload-Hint und fetchpriority="high" – allein dieser Schritt brachte 1,8 s LCP-Reduktion.font-display:swap umgestellt und das Hauptgewicht per preload priorisiert – weitere 0,4 s LCP gewonnen.defer/async umgestellt und in einer Bundle-Datei konsolidiert – INP fiel von 340 ms auf 140 ms.Wenn Sie eine vergleichbare Analyse Ihrer Website wünschen, schauen Sie unsere SEO Audit Checkliste an oder beauftragen Sie unser Technical SEO Team.
Simulierte Tests unter kontrollierten Bedingungen. Schnell, reproduzierbar, gut für Entwicklung und A/B-Tests.
Echte Nutzerdaten aus dem Chrome User Experience Report (CrUX). Diese Daten verwendet Google tatsächlich für Rankings.
Core Web Vitals sind ein Tiebreaker-Signal: Bei inhaltlich gleichwertigen Seiten gewinnt die mit besserer Page Experience. In der Praxis sind starke Keywords, Backlinks und Content-Qualität stärker. Allerdings: Sehr schlechte Core Web Vitals (roter Bereich) können Rankings aktiv schädigen.
Google bewertet Core Web Vitals auf Seiten-Ebene, nicht auf Domain-Ebene. Priorisieren Sie: (1) Landingpages mit hohem Traffic, (2) Seiten, die für wichtige Keywords ranken sollen, (3) Conversion-relevante Seiten. Die Startseite ist wichtig, aber oft nicht die kritischste Seite.
Die schnellsten LCP-Verbesserungen: (1) Bilder in WebP/AVIF konvertieren, (2) Größte Bilder mit loading="eager" und fetchpriority="high" priorisieren, (3) CDN einsetzen, (4) Server-Response-Time optimieren (TTFB unter 800ms), (5) Render-blockendes CSS/JS eliminieren.
Core Web Vitals (Field-Daten) sind für Google-Rankings relevant, nicht der PageSpeed-Score. Ein hoher PageSpeed-Score (Lab-Daten) korreliert oft mit guten Core Web Vitals, ist aber kein direkter Rankingfaktor. Fokussieren Sie auf die Field-Daten in der Google Search Console.
Für Lab-Daten: PageSpeed Insights, Lighthouse (Chrome DevTools), WebPageTest. Für Field-Daten: Google Search Console (CWV-Bericht), Chrome UX Report, RUM-Tools wie SpeedCurve oder Calibre. Field-Daten sind aussagekräftiger, weil sie echte Nutzer messen — Google nutzt sie auch für das Ranking.
Kostenlos: PageSpeed Insights, Lighthouse (Chrome DevTools), Google Search Console CWV-Bericht. Premium: WebPageTest, SpeedCurve oder Calibre für RUM und CI/CD-Integration. Für Image-Optimierung: Squoosh, ImageMagick, Cloudflare Image Resizing oder ein dediziertes Image-CDN wie Cloudinary. Konkrete Tool-Empfehlungen finden Sie in unserer SEO Audit Checkliste.
Lab-Daten (PageSpeed Insights, Lighthouse) simulieren einen einzelnen Aufruf unter festen Bedingungen. Die Search Console zeigt dagegen Field-Daten echter Nutzer — inklusive langsamer Mobilgeräte, schwacher Netzverbindungen und Erstbesuchen ohne Cache. Die häufigste Ursache der Diskrepanz ist INP: Im Labortest interagiert niemand mit der Seite, echte Nutzer schon. Priorisieren Sie deshalb immer die Field-Daten.
Der Chrome User Experience Report arbeitet mit einem rollierenden 28-Tage-Fenster. Nach einer technischen Verbesserung dauert es also bis zu vier Wochen, bis die Field-Daten in der Google Search Console vollständig im grünen Bereich sind. Ranking-Effekte folgen danach schrittweise — planen Sie insgesamt sechs bis acht Wochen ein, bevor Sie die Wirkung bewerten.
Unser Technical SEO Service analysiert Ihre Core Web Vitals und implementiert gezielte Verbesserungen.
Performance-Audit anfordern →