Was sind Core Web Vitals? Der klare Leitfaden für bessere UX & SEO

Was sind Core Web Vitals? Core Web Vitals sind von Google definierte Leistungs- und Nutzererlebnis-Kennzahlen, die messen, wie schnell, stabil und reaktionsfähig eine Website aus Sicht echter Nutzer ist. Sie wirken sich nicht nur auf die Zufriedenheit deiner Besucher aus, sondern sind auch Teil der Google-Bewertung im Rahmen von „Page Experience“. In diesem Guide erfährst du, welche Metriken zählen, welche Grenzwerte du anpeilen solltest, wie du korrekt misst und welche Hebel in der Praxis die größten Verbesserungen bringen.

Core Web Vitals: Bedeutung und Einordnung für SEO

Core Web Vitals sind ein standardisierter Satz an Messwerten, mit denen Google die Qualität der Seitenerfahrung beurteilt. Wichtig ist die Einordnung: Sie ersetzen keine Inhalte oder Relevanzsignale, aber sie können den Ausschlag geben, wenn mehrere Ergebnisse inhaltlich ähnlich gut sind. Gleichzeitig verbessern gute Werte fast immer die Conversion, weil Seiten schneller reagieren und weniger „wackeln“.

Die Core Web Vitals sind eng verwandt mit dem Thema Page Speed, gehen aber darüber hinaus: Statt nur „wie schnell lädt die Seite?“ zu fragen, messen sie ganz konkret, wann der Hauptinhalt sichtbar ist, wie schnell Interaktionen möglich sind und ob Layouts unerwartet springen.

Warum Google diese Kennzahlen eingeführt hat

Google will Suchenden Ergebnisse liefern, die nicht nur inhaltlich passen, sondern auch angenehm nutzbar sind. Schlechte UX sorgt für schnelle Absprünge, Frust und geringeres Vertrauen in Marke und Angebot. Core Web Vitals liefern dafür objektive Messpunkte.

Rankingfaktor ja – aber richtig verstanden

Die Metriken sind ein Signal unter vielen. Du solltest sie als Performance-Basis sehen: Wenn deine Werte schlecht sind, verschenkst du Potenzial. Wenn sie gut sind, entsteht ein sauberer technischer Unterbau, auf dem SEO und Conversion besser funktionieren – etwa in Verbindung mit einer starken Conversion Rate und klaren Nutzerwegen.

• Relevanz bleibt Kern: Content & Suchintention dominieren weiterhin.
• UX wirkt indirekt: Bessere Werte reduzieren Absprünge und erhöhen Interaktionen.
• Technische Hygiene: Core Web Vitals zwingen zu schlankem Frontend und gutem Hosting.

Die drei Core Web Vitals im Überblick (LCP, INP, CLS)

Aktuell bestehen die Core Web Vitals aus drei Metriken: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) und CLS (Cumulative Layout Shift). Jede Metrik steht für einen konkreten Teil der User Experience. Entscheidend: Google bewertet typischerweise anhand des 75. Perzentils echter Nutzerdaten (CrUX). Das heißt: Nicht die Best-Case-Ladezeit zählt, sondern wie es bei den meisten echten Nutzern läuft.

Largest Contentful Paint (LCP): Wahrgenommene Ladegeschwindigkeit

LCP misst, wann das größte sichtbare Inhaltselement im Viewport gerendert ist (z. B. Hero-Bild, großes Text- oder Block-Element). Es beantwortet die Nutzerfrage: „Ist die Seite schon da?“

• Gut: ≤ 2,5 Sekunden
• Verbesserungswürdig: 2,5–4,0 Sekunden
• Schlecht: > 4,0 Sekunden

Interaction to Next Paint (INP): Reaktionsfähigkeit

INP ist der modernere Nachfolger von FID und misst, wie schnell eine Seite nach einer Nutzerinteraktion (Klick, Tap, Tastatur) visuell reagiert. Hier geht es um „fühlt sich die Seite schnell an?“ – oft ein JavaScript-Thema.

• Gut: ≤ 200 ms
• Verbesserungswürdig: 200–500 ms
• Schlecht: > 500 ms

Cumulative Layout Shift (CLS): Visuelle Stabilität

CLS misst, wie stark sich Layout-Elemente während des Ladens unerwartet verschieben. Das ist der Moment, in dem du „Kaufen“ klicken willst – und der Button springt weg. CLS ist besonders wichtig für Vertrauen und Conversion.

• Gut: ≤ 0,1
• Verbesserungswürdig: 0,1–0,25
• Schlecht: > 0,25

Welche Grenzwerte wirklich zählen (Mobile, Desktop, 75. Perzentil)

In der Praxis scheitern viele Websites nicht an einzelnen Ausreißern, sondern an der Bewertungssystematik: Google betrachtet primär reale Felddaten und davon das 75. Perzentil. Das bedeutet: 75 % deiner Nutzer müssen die „guten“ Schwellenwerte erreichen, damit die Seite als „good“ gilt. Gerade bei Mobile ist das herausfordernd, weil Geräte langsamer, Netze instabiler und Seiten oft schwerer sind.

Mobile zuerst denken

Auch wenn dein Desktop im Test „grün“ ist, kann Mobile im Feld „gelb/rot“ sein. Mobile Optimierung hängt stark zusammen mit Responsive Webdesign (Layout, Bildgrößen, Breakpoints) – aber vor allem mit Payload: weniger JS, weniger große Bilder, weniger Third-Party.

URL-Level vs. Origin-Level

Google kann Core Web Vitals pro URL und pro Origin (Domain/Host) ausweisen. Wenn viele Unterseiten ähnlich gebaut sind (gleiches Template), wirken Optimierungen oft breit. Umgekehrt kann ein einzelnes „schweres“ Template (z. B. Landingpage mit vielen Skripten) die Wahrnehmung deiner Performance in einem ganzen Bereich verschlechtern.

• Schwellenwerte sind fix, aber die Messrealität variiert stark nach Gerät und Netz.
• 75. Perzentil ist entscheidend: Optimiere für „die Mehrheit“, nicht für den Ideal-Test.
• Templates zählen: Häufig ist das Problem systemisch, nicht eine Einzelseite.

So misst du Core Web Vitals korrekt: Tools und Datenquellen

Wer „Was sind Core Web Vitals?“ verstehen will, muss auch wissen, wie man sie misst. Der wichtigste Unterschied: Lab-Daten (synthetische Tests) vs. Field-Daten (echte Nutzer). Lab-Daten helfen beim Debugging, Field-Daten entscheiden, wie Google deine Seite im Alltag sieht.

Lab: Lighthouse & PageSpeed Insights

Mit Lighthouse und PageSpeed Insights bekommst du konkrete Hinweise auf Performance-Bremsen. Das ist ideal, um Hypothesen zu testen (z. B. „Blockiert ein Script den Main-Thread?“). Aber: Ein einzelner Testlauf ist nicht repräsentativ für alle Nutzer.

• Lighthouse: reproduzierbar, gut für Entwicklersprints
• PageSpeed Insights: kombiniert Lab + (wenn vorhanden) Field-Daten

Field: CrUX, Search Console, RUM

Die Google Search Console zeigt dir Core Web Vitals in Clustern („URLs mit ähnlichen Problemen“). Für kontinuierliche Optimierung ist zusätzlich echtes Monitoring sinnvoll (RUM = Real User Monitoring), weil du damit Ursachen nach Gerät, Browser, Seite und Interaktion auswerten kannst.

Wichtig: Messung ist nur dann hilfreich, wenn du sie in eine Routine bringst. Ein guter Prozess ist: messen → priorisieren → fixen → validieren → überwachen.

1. In Search Console Problemgruppen identifizieren
2. Betroffene Templates und Komponenten zuordnen
3. Mit Lighthouse reproduzieren und Engpass finden
4. Fix deployen, danach „Validate Fix“ starten

Wenn du ohnehin technische SEO-Checks machst, lohnt sich auch ein Blick auf Themen wie SEO-Fehler, weil Core-Web-Vitals-Probleme oft mit allgemeinen technischen Schwächen zusammen auftreten (zu viele Skripte, unoptimierte Assets, fehlendes Caching).

Typische Ursachen für schlechten LCP (und wie du sie behebst)

Ein schlechter LCP entsteht fast immer durch zu langsames Ausliefern oder Rendern des „größten Elements“. Häufig ist das ein Hero-Bild, manchmal aber auch ein großer Textblock oder ein Slider. Der Schlüssel ist, alles zu optimieren, was vor dem ersten sichtbaren Content passiert: Serverantwort, Render-Blocking, Bild-Pipeline.

Server & Auslieferung: TTFB, Hosting, Caching

Wenn die erste Serverantwort langsam ist, startet der Browser spät. Prüfe Hosting-Leistung, PHP/DB-Performance (bei CMS) und Caching. Passend dazu: Ein solides Setup beginnt bei Hosting und kann durch ein Content Delivery Network (CDN) deutlich profitieren.

• Full-Page-Caching aktivieren (wo sinnvoll)
• CDN für statische Assets und internationale Zielgruppen
• Kompression (Brotli/Gzip) und HTTP/2/3

Render-Blocking reduzieren

CSS und JavaScript können den ersten Render verzögern. Minifiziere CSS, lade nicht kritisches JS „defer“, und halte Third-Party-Skripte schlank. Prüfe auch Fonts: Externe Schrift-Requests können LCP verschlechtern. Oft hilft es, Google Fonts lokal zu laden, um Requests zu reduzieren und Datenschutz/Performance gleichzeitig zu verbessern.

Bilder richtig ausliefern

Für LCP-Bilder gilt: richtiges Format (AVIF/WebP), richtige Größe, „preload“ für das LCP-Asset, Lazy-Loading nicht für das LCP-Element. Und vermeide schwere Slider: Ein statisches Hero kann schneller und conversionstärker sein.

Merke: LCP ist oft der schnellste Hebel mit messbarem Effekt – vor allem, wenn du ein klares Above-the-Fold-Konzept hast und diesen Bereich konsequent leicht hältst.

INP verbessern: JavaScript, Third-Party und Main-Thread entlasten

INP ist in vielen Projekten der schwierigste Wert, weil er stark von JavaScript und der Interaktionslogik abhängt. Vereinfacht: Wenn der Browser „beschäftigt“ ist, kann er Klicks nicht schnell genug verarbeiten. Das ist typischerweise ein Problem auf Seiten mit vielen Widgets, Trackern, Chat-Tools oder komplexen Frontend-Frameworks.

Die häufigsten INP-Bremsen

• Zu viel JavaScript (große Bundles, unnötige Bibliotheken)
• Long Tasks auf dem Main-Thread (z. B. Rendering, Parsing)
• Third-Party-Skripte (Tags, Pixel, Consent, A/B-Tools)
• Komplexe DOM-Strukturen (viele Nodes, teure Layout-Berechnungen)

Konkrete Maßnahmen mit hoher Wirkung

Fokussiere dich auf „weniger und später“: weniger JS insgesamt, und alles, was nicht sofort gebraucht wird, später laden. Nutze Code-Splitting, entferne ungenutzte Features und prüfe, ob du wirklich mehrere Tracking-Lösungen parallel brauchst. Wenn du Experimente fährst, achte darauf, dass Test-Tools nicht alles ausbremsen – und setze A/B-Tests so auf, dass Performance nicht kollabiert.

1. Audit: Welche Skripte sind wirklich nötig?
2. Priorisieren: Interaktive Kernfunktionen zuerst
3. Aufräumen: JS reduzieren, Long Tasks splitten
4. Nachmessen: INP im Feld beobachten

Eine gute Faustregel: Jede zusätzliche Third-Party-Integration hat einen „Performance-Preis“. Wenn du Conversion-Tools nutzt, verknüpfe Performance immer mit dem Nutzen – sonst zahlst du INP mit schlechter UX.

CLS senken: Layout-Sprünge durch Bilder, Fonts und Ads vermeiden

CLS ist der „Vertrauens-Metrik“ unter den Core Web Vitals. Nutzer nehmen Layout-Sprünge extrem negativ wahr – besonders, wenn sie gerade lesen oder klicken wollen. Die Ursachen sind oft banal: fehlende Größenangaben, dynamisch nachgeladene Elemente oder Fonts, die erst spät verfügbar sind und dann den Text umformatieren.

Die größten CLS-Verursacher

• Bilder/Videos ohne feste Dimensionen (width/height oder aspect-ratio)
• Embeds (Maps, iFrames, Social Widgets), die erst später Höhe bekommen
• Cookie-Banner oder Promo-Leisten, die Content nach unten drücken
• Webfonts, die spät laden (FOIT/FOUT), dadurch Reflow
• Werbe-/Tracking-Slots ohne reservierten Platz

Best Practices für stabile Layouts

Reserviere Platz: Gib Medien feste Seitenverhältnisse, plane Containerhöhen für dynamische Bereiche und setze UI-Elemente so um, dass sie Inhalte nicht „wegschieben“. Besonders wichtig ist die Navigation und der obere Bereich: Ein stabiler Header verhindert viele Probleme im Above-the-Fold-Bereich.

Bei Fonts helfen Preload, lokale Auslieferung und passende Font-Display-Strategien. Wenn du ohnehin an deiner Technik arbeitest, ist es sinnvoll, Performance nicht isoliert zu betrachten, sondern als Teil einer „guten Website“-Basis – siehe auch was eine gute Website auszeichnet.

1. Für jedes Bild/Video: feste Maße oder aspect-ratio definieren
2. Für dynamische Module: Platzhalter/Containerhöhe vorab reservieren
3. Cookie-/Hinweisleisten: Overlay statt Push (wenn UX-konform)
4. Fonts optimieren (Preload, lokal, Subsetting)

Core Web Vitals in der Praxis: Priorisierung nach Templates und Business-Zielen

Performance-Projekte scheitern selten an fehlendem Wissen, sondern an falscher Priorisierung. Statt „alles optimieren“ brauchst du eine klare Reihenfolge: Welche Seitentypen bringen Traffic, Leads, Umsatz? Welche Templates erzeugen die meisten schlechten Werte? Ein gezielter Ansatz bringt schneller Ergebnisse und ist intern leichter zu verkaufen.

Die sinnvollste Reihenfolge für die meisten Websites

• Startseite (meist hoher Traffic, viele First-Time-User)
• Leistungs-/Produktseiten (Conversion-nah)
• Landingpages aus Kampagnen (Paid Traffic ist teuer)
• Blog/Content-Templates (Skaleneffekt über viele URLs)

Gerade Landingpages profitieren doppelt: Bessere UX hebt oft direkt die Ergebnisse deiner Conversion-Optimierung. Gleichzeitig verringert sich die Abhängigkeit von „Tricks“, weil Nutzer ohne Reibung durch den Funnel laufen.

Dokumentiere Maßnahmen wie ein Mini-Case

Lege vor dem Fix fest, was du erwartest (z. B. LCP von 3,8s auf 2,4s; Absprungrate -10 %). Nach dem Rollout misst du nach und dokumentierst, was wirklich passiert ist. So werden Core Web Vitals vom „Tech-Thema“ zum Business-Hebel.

Ein weiterer Praxispunkt: Wenn du CMS-basiert arbeitest (z. B. WordPress), hängen viele Probleme an Themes, Page Buildern und Plugins. Weniger ist oft mehr – und ein sauberes Template-Design schlägt jede „Optimierungs-App“.

Häufige Missverständnisse und schnelle Checks vor dem Relaunch

Rund um Core Web Vitals kursieren viele Halbwahrheiten. Ein häufiger Fehler ist, sich nur auf Lighthouse-Scores zu fixieren oder einzelne Werte „grün“ zu bekommen, während echte Nutzer weiterhin Probleme haben. Ebenso gefährlich: Relaunches, bei denen neue Designs, neue Tracking-Stacks und neue Komponenten live gehen, ohne Performance-Budget.

Typische Irrtümer

• „Score 100 = alles gut“: Entscheidend sind Felddaten und reale Nutzerwege.
• „Nur Bilder komprimieren“: LCP kann auch durch Server, CSS, JS entstehen.
• „Mehr Tools = mehr Erkenntnis“: Zu viele Skripte verschlechtern INP.
• „Mobile ist nur Design“: Mobile ist vor allem Payload + CPU + Netz.

Performance-Budget vor Änderungen festlegen

Definiere vor einem Relaunch harte Grenzen: maximale JS-Größe, maximale Bildgewichte im Header, erlaubte Third-Party-Skripte. Das verhindert, dass Performance „nebenbei“ kaputtgeht. Wenn du ohnehin einen Relaunch planst, ist es sinnvoll, Performance als Pflichtpunkt zu integrieren – ähnlich wie bei einem sauberen Website-Relaunch-Ablauf und der Frage, wie man einen Relaunch ohne Ranking-Verlust umsetzt.

Ein schneller Preflight-Check vor Go-Live:

1. Core Web Vitals der wichtigsten Templates im Staging testen
2. Third-Party-Liste prüfen und reduzieren
3. Bild- und Font-Strategie festzurren
4. Monitoring (RUM/Logs) für die ersten Wochen nach Launch aktivieren