Was Core Web Vitals wirklich an Umsatz kosten

Core Web Vitals werden meist als reines SEO-Thema diskutiert. Das greift zu kurz: Als Rankingsignal sind sie nachweislich untergeordnet – Google hat selbst klargestellt, dass eine langsamere Seite mit dem besseren Inhalt eine schnelle Seite mit schlechterem Inhalt jederzeit übertrifft.

Der eigentliche Hebel ist die Conversion Rate. Ein Besucher, der abspringt, bevor die Seite gerendert ist, konvertiert zu null Prozent – und das lässt sich durch kein Ranking der Welt ausgleichen.

Hier erfahren Sie, was die drei Metriken messen, was schlechte Werte verursacht und was Sie zuerst beheben sollten.

Die drei Kernmetriken

Largest Contentful Paint (LCP)

Der Zeitpunkt, an dem das größte sichtbare Inhaltselement gerendert ist. Meist das Hero-Image, die H1-Überschrift oder ein großer Textblock.

Gut: unter 2,5 Sekunden
Verbesserungsbedürftig: 2,5–4,0 Sekunden
Schlecht: über 4,0 Sekunden

Der LCP ist der beste Indikator dafür, wann eine Seite für den Nutzer nutzbar wird. Das ist die Metrik mit der höchsten Priorität.

Cumulative Layout Shift (CLS)

Wie stark Inhalte während des Ladevorgangs springen. Jeder kennt das: Sie wollen auf einen Link tippen, eine Werbeanzeige lädt nach, die Seite verschiebt sich und Sie tippen daneben.

Gut: unter 0,1
Schlecht: über 0,25

Der CLS ist meist am schnellsten und günstigsten zu beheben, da die Ursachen bekannt und eindeutig sind.

Interaction to Next Paint (INP)

Wie lange die Seite braucht, um auf Interaktionen visuell zu reagieren. Hat im März 2024 den First Input Delay (FID) abgelöst und ist deutlich strenger: Gemessen wird jede Nutzerinteraktion während des gesamten Besuchs, nicht nur die erste.

Gut: unter 200 ms
Schlecht: über 500 ms

Ein schlechter INP ist fast immer ein JavaScript-Problem: Der Main Thread ist überlastet und kann das Interface nicht neu zeichnen.

Labordaten versus Felddaten

Diese Unterscheidung sorgt häufig für Verwirrung:

Labordaten entstehen durch simulierte Messungen unter kontrollierten Bedingungen – genau das, was Google Lighthouse in den Chrome DevTools liefert. Reproduzierbar und wertvoll fürs Debugging, aber nicht das, was Google für Rankings heranzieht.

Felddaten stammen aus dem Chrome User Experience Report (CrUX): Echte Messwerte von realen Chrome-Nutzern über ein rollierendes 28-Tage-Fenster. Das ist die reale Basis, die Google verwendet und die in der Search Console erscheint.

Beide Werte weichen regelmäßig voneinander ab – und im Zweifel zählen immer die Felddaten. Eine Website kann in Lighthouse auf dem schnellen Entwickler-Rechner 95 Punkte erzielen, aber im Feld durchfallen, weil reale Nutzer mit Mittelklasse-Smartphones in überlasteten Mobilfunknetzen surfen.

Praxiskonsequenz: Optimieren Sie nach Felddaten, nutzen Sie Labordaten zum Debuggen. Beachten Sie, dass Felddaten zeitverzögert reagieren: Verbesserungen zeigen sich erst über bis zu 28 Tage im vollen Umfang.

Unser kostenloses SEO-Audit-Tool zeigt beide Datenquellen direkt aus der Google PageSpeed Insights API an.

Häufigste Ursachen für schlechte LCP-Werte

Nach Häufigkeit in der Praxis geordnet:

1. Nicht optimierte Bilder

Auf den meisten Seiten ist das LCP-Element ein Bild, das oft viel zu groß ausgeliefert wird.

Das typische Fehlerbild: Ein 700 KB schweres JPEG mit 3000 px Breite, das auf 640 px skaliert angezeigt wird – ohne modernes Format und ohne Prioritätshinweis.

Die Lösung:

<picture>
  <source srcset="/hero-640.avif 640w, /hero-1280.avif 1280w" type="image/avif" />
  <source srcset="/hero-640.webp 640w, /hero-1280.webp 1280w" type="image/webp" />
  <img src="/hero-640.jpg" alt="…"
       width="640" height="480"
       fetchpriority="high" decoding="async" />
</picture>

Was hier passiert: AVIF und WebP reduzieren die Dateigröße bei gleicher Qualität um 50–80 % gegenüber JPEG. srcset liefert Smartphones die passende Auflösung. width und height reservieren den Platz (verhindert CLS). Und fetchpriority="high" signalisiert dem Browser, dass dieses Bild vor allen anderen Ressourcen geladen werden muss.

Dieses Attribut ist oft der größte Hebel für sofortige LCP-Gewinne.

Wichtig: Setzen Sie niemals loading="lazy" auf Ihr LCP-Hero-Bild! Lazy Loading verzögert den Download genau des Elements, auf das es ankommt. Lazy-loaden Sie alles unterhalb des sichtbaren Bereichs (Below the Fold); das Hero-Bild gehört priorisiert geladen.

2. Rendering-blockierende Ressourcen

Jedes Stylesheet im Head und jedes synchrone Skript blockiert das Rendern der Seite.

Der klassische Fehler sind verkettete @import-Aufrufe:

/* in styles.css — erzeugt unnötige Ladeketten */
@import url('https://fonts.googleapis.com/css2?family=…');

Der Browser lädt styles.css, parst die Datei, entdeckt den Import, lädt das Font-CSS nach, parst dieses und fordert erst dann die Schriftdateien an. Vier aufeinanderfolgende Roundtrips, bevor der erste Buchstabe sichtbar wird.

Binden Sie Webfonts direkt im HTML-Head ein, kombiniert mit preconnect:

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=…&display=swap" />

display=swap sorgt dafür, dass Text sofort mit einer Systemschrift dargestellt wird, anstatt unsichtbar zu bleiben, bis die Webfont geladen ist.

3. Hohe Server-Antwortzeit (TTFB)

Wenn die Time to First Byte über 600 ms liegt, kann die Seite nicht schnell sein. Typische Ursachen: Fehlendes Caching, leistungsschwaches Hosting, ungecachte Datenbankabfragen bei jedem Aufruf oder ein CDN, das nicht vorgeschaltet ist.

Für Unternehmens-Websites ist statische Generierung (SSG) die beste Lösung: Seiten als fertiges HTML auszuliefern ist unschlagbar schnell.

4. Zu viel JavaScript

Ein Framework, das 400 KB JavaScript lädt, um schlichten Text darzustellen, vergeudet wertvolle Ladezeit. Auf einem Mobiltelefon kann das Parsen und Ausführen dieser Datenmengen über eine Sekunde dauern, bevor Inhalte sichtbar werden.

Ursachen für schlechten CLS

Drei Fehler erklären fast alle Layout-Verschiebungen:

Bilder ohne Breiten- und Höhenangaben: Ohne width und height kann der Browser keinen Platz freihalten – der Inhalt darunter springt nach unten, sobald das Bild lädt.
Nachladende Webfonts: Die Systemschrift wird gerendert, die Webfont lädt mit anderen Abmessungen nach und der Text bricht neu um. Lösung: font-display: swap mit angepassten Metriken über size-adjust.
Dynamisch oberhalb eingefügte Inhalte: Cookie-Banner, Hinweisleisten oder nachträglich geladene Banner schieben den gesamten Seiteninhalt nach unten. Halten Sie den Platz frei oder positionieren Sie Elemente als Overlay.

Ursachen für schlechten INP

INP misst die Blockierung des Main Threads:

Long Tasks: Einzelne JavaScript-Aufgaben von über 50 ms Dauer blockieren Eingaben.
Schwere Event Handler: Komplexe Berechnungen direkt im Klick- oder Scroll-Handler.
Drittanbieter-Skripte: Tracking-Pixel, Chat-Widgets, Heatmaps und A/B-Testing-Tools konkurrieren um Rechenzeit.
Exzessives Re-Rendering: Frameworks, die bei jedem Tastenanschlag den gesamten DOM-Baum neu berechnen.

Lösungsansätze nach Hebelwirkung:

Drittanbieter-Skripte bereinigen: Unnötige Tags löschen; den Rest mit defer oder erst nach Nutzerinteraktion laden.
Lange Tasks aufbrechen: Rechenzeit über scheduler.yield() oder setTimeout(…, 0) an den Main Thread zurückgeben.
Event-Handler entprellen (Debounce): Insbesondere bei input- und scroll-Events.
Aufwendige Berechnungen in Web Worker auslagern.

Prioritätenliste für maximale Wirkung

Bei begrenzter Zeit in dieser Reihenfolge vorgehen:

LCP-Bild komprimieren, skalieren und fetchpriority="high" setzen. Meist die größte Einzelverbesserung.
width und height für alle Bilder hinterlegen. Behebt den Großteil aller CLS-Probleme.
Rendering-blockierende @import-Ketten entfernen. Fonts per preconnect in den Head verschieben.
Drittanbieter-Tags ausmisten. Verbessert LCP und INP gleichzeitig.
Bilder unterhalb des Folds mit loading="lazy" versehen. Hero-Bilder immer eager laden.
TTFB optimieren, falls dieser über 600 ms liegt.

Fazit: Die Punktzahl richtig einordnen

Die Jagd nach perfekten 100 Punkten in Lighthouse ist selten wirtschaftlich sinnvoll. Der Unterschied zwischen 85 und 100 Punkten verändert das Nutzerverhalten kaum – der Sprung von 35 auf 75 Punkte hingegen massiv.

Bringen Sie Ihre Werte in den grünen Bereich der Felddaten und konzentrieren Sie sich anschließend wieder auf Conversion-Pfade und Ihr Angebot. Performance ist ein Werkzeug für mehr Umsatz – kein Selbstzweck.

Wählen Sie Ihre Sprache