Core Web Vitals

Die drei Werte und ihre Schwellen

Jede Seite wird in drei Dimensionen gemessen. Grün ist sie nur, wenn alle drei Werte im guten Bereich liegen.

Gemeint ist beim LCP das größte sichtbare Element im ersten Bildschirmbereich — meist das Hero-Bild oder die Hauptüberschrift. CLS ist ein Verhältniswert ohne Einheit. Alles zwischen den beiden Spalten gilt als verbesserungswürdig. Entscheidend ist dabei nicht der Durchschnitt, sondern das 75. Perzentil: Drei von vier Seitenaufrufen müssen die Schwelle einhalten. Mobil und Desktop werden getrennt bewertet — und Mobil ist fast immer der kritischere Fall.

INP hat im März 2024 den früheren Wert FID (First Input Delay) ersetzt. FID maß nur die Verzögerung der ersten Interaktion und fiel deshalb fast überall gut aus. INP betrachtet alle Interaktionen eines Besuchs und rückt damit langsame Menüs, träge Filter und blockierende Skripte in den Blick.

Felddaten oder Labordaten

Das ist der Punkt, an dem die meisten Diskussionen entstehen. Es gibt zwei Quellen, und nur eine davon zählt für Google:

• Felddaten (CrUX): Der Chrome User Experience Report sammelt anonymisierte Messwerte echter Chrome-Nutzer mit aktivierter Datenfreigabe, über ein rollierendes Fenster der letzten 28 Tage. Diese Daten stehen oben in PageSpeed Insights und im Core-Web-Vitals-Bericht der Search Console. Sie sind die Grundlage der Bewertung.
• Labordaten (Lighthouse): Ein einmaliger Test unter simulierten Bedingungen. Praktisch zur Fehlersuche, aber kein Urteil. Lighthouse kann INP gar nicht messen — es gibt ja keinen echten Nutzer, der klickt — und weist ersatzweise die Total Blocking Time aus.

Zeigt PageSpeed Insights „Nicht genügend Daten”, waren schlicht zu wenige Besucher unterwegs. Das ist kein Fehler, sondern ein Hinweis auf geringen Traffic.

Was die Werte in der Praxis verschlechtert

Die Ursachen wiederholen sich. In dieser Reihenfolge lohnt sich die Prüfung:

LCP — zu große, nicht komprimierte Hero-Bilder, spät geladene Schriften, ein Slider oder Page-Builder, der den Hero erst per JavaScript aufbaut, oder eine langsame Server-Antwortzeit.

INP — zu viel JavaScript im Hauptthread: Tracking-Skripte, Chat-Widgets, Cookie-Banner, Animationsbibliotheken. Jedes Skript, das nicht sofort gebraucht wird, gehört verzögert geladen.

CLS — Bilder ohne festgelegte Maße, nachträglich eingeblendete Banner, Schriftwechsel beim Laden, Werbeflächen ohne reservierten Platz.

Ein großer Teil davon lässt sich im HTML lösen:

<!-- Maße reservieren den Platz, bevor das Bild da ist: kein Layout-Sprung -->
<img src="/hero.webp" width="1200" height="675" alt="…"
     fetchpriority="high" decoding="async">

<!-- Nicht kritische Skripte blockieren den Aufbau nicht mehr -->
<script src="/js/slider.js" defer></script>

/* Text bleibt sichtbar, während die Schrift lädt — verhindert CLS und leere Flächen */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
}

Mehr dazu in der Anleitung zur Ladezeit-Optimierung.

Wie stark wirken die Werte auf das Ranking?

Vorsichtig formuliert: Die Core Web Vitals sind ein Signal unter vielen und gehören zu den Signalen rund um die Seitenerfahrung. Google hat mehrfach klargestellt, dass ein passender Inhalt schwerer wiegt als eine schnelle Seite. Wer mit grünen Werten allein Positionen kaufen will, wird enttäuscht.

Der handfestere Effekt liegt woanders: Eine Seite, die in zwei Sekunden steht und beim Tippen sofort reagiert, verliert weniger Besucher, bevor sie überhaupt gelesen wird. Das wirkt direkt auf die Conversion Rate — und zwar unabhängig davon, wie Google die Werte gewichtet.

Sinnvolle Reihenfolge: erst die technischen Ursachen beheben, dann die OnPage-Optimierung nachziehen. Ob eine Seite überhaupt in den Index kommt, entscheidet sich ohnehin vorher — siehe Indexierung.