Core Web Vitals

Warum das zählt

Google bestätigt in seiner Dokumentation, dass die Core Web Vitals von den Ranking-Systemen genutzt werden. Im selben Dokument steht aber auch, dass es kein einzelnes Signal für das Seitenerlebnis gibt und dass die Suche weiterhin den relevantesten Inhalt zeigt, selbst wenn dessen Seitenerlebnis mäßig ist. Ein Gewicht beziffert Google nicht.

Daraus folgt eine nüchterne Einordnung. Eine schnelle Seite mit Thin Content überholt keine langsame Seite mit starkem Inhalt. Erst wenn mehrere Ergebnisse inhaltlich gleichauf liegen, kann das bessere Seitenerlebnis den Ausschlag geben.

Der eigentliche Grund, sich damit zu befassen, liegt vor dem Ranking. Eine Seite, die spät reagiert oder deren Inhalte während des Aufbaus verspringen, verliert Besucher, bevor sie gelesen wird. Wer auf einen falschen Button tippt, weil sich das Layout gerade verschoben hat, kommt selten zurück. Damit schlagen die Werte direkt auf die Conversion Rate durch, und dieser Effekt ist messbar, ohne auf Ranking-Schwankungen zu warten.

Wie es funktioniert

Drei Messwerte mit jeweils drei Bewertungsbereichen. Der gute Bereich muss für 75 Prozent der Seitenaufrufe erreicht werden, getrennt nach Mobilgeräten und Rechnern. Die folgenden Schwellen weist Google im Bericht zu den Core Web Vitals in der Search Console aus.

Das 75. Perzentil bedeutet: Drei von vier Aufrufen erreichen den Wert oder sind schneller. Ein Durchschnitt wäre irreführend, weil einzelne sehr schnelle Aufrufe viele langsame verdecken. Es zählt also nicht der beste Fall, sondern der Rand des Normalbereichs.

Der Wert INP hat am 12. März 2024 den älteren Wert FID abgelöst. FID, kurz für First Input Delay, maß nur die Verzögerung vor der Verarbeitung der allerersten Eingabe. INP betrachtet die Interaktionen eines gesamten Seitenbesuchs und misst die volle Spanne bis zur sichtbaren Reaktion. Der Maßstab ist damit deutlich strenger. Wer noch Berichte oder Zielwerte mit FID pflegt, arbeitet mit einer abgeschafften Kennzahl.

Entscheidend ist die Unterscheidung zweier Datenquellen. Labordaten entstehen in einem simulierten Test unter festgelegten Bedingungen, etwa in Lighthouse oder im unteren Teil von PageSpeed Insights. Felddaten stammen aus echten Besuchen und werden im Chrome User Experience Report gesammelt, kurz CrUX. Nur die Felddaten fließen in die Bewertung ein. Die Search Console zeigt dafür jeweils die vergangenen 28 Tage. Ein guter Laborwert bei schlechten Felddaten bedeutet, dass die Testbedingungen freundlicher waren als die Realität Ihrer Besucher.

Seiten mit wenig Verkehr erscheinen im Bericht unter Umständen gar nicht, weil eine Mindestmenge an Daten nötig ist. Google fasst ähnliche Seiten deshalb zu Gruppen zusammen und bewertet die Gruppe.

In der Praxis

Für die Prüfung hat sich eine feste Reihenfolge bewährt. Sie führt schneller zum Ergebnis als das wahllose Testen einzelner Seiten.

1. Bericht zu den Core Web Vitals in der Google Search Console öffnen und mit der Ansicht für Mobilgeräte beginnen.
2. Die Gruppe mit dem schlechtesten Wert auswählen und sich die Beispiel-URLs anzeigen lassen.
3. Eine dieser URLs in PageSpeed Insights prüfen. Oben stehen die Felddaten aus CrUX, unten die Labordiagnose mit den konkreten Hinweisen.
4. Die Ursache beheben, nicht den Punktwert. Ein Hinweis, der 0,02 Sekunden bringt, ist kein Arbeitsauftrag.
5. Nach dem Livegang in der Search Console die Prüfung anstoßen. Die Validierung läuft über einen 28-Tage-Zeitraum, weil die Felddaten so lange nachlaufen.

Die Ursachen sind über Projekte hinweg erstaunlich stabil. Beim LCP sind es zu große Bilder in veralteten Formaten und Skripte von Drittanbietern, die den Aufbau blockieren. Beim INP sind es umfangreiche Skripte, die den Hauptprozess des Browsers belegen, während der Nutzer schon tippt. Beim CLS sind es Bilder und eingebettete Elemente ohne feste Größenangabe sowie nachträglich eingeblendete Banner.

Gegen das Verspringen hilft ein einfacher Handgriff: Breite und Höhe gehören ins HTML, damit der Browser den Platz reserviert, bevor die Datei da ist. Das CSS sorgt dafür, dass das Bild trotzdem mitskaliert.

<img src="/bilder/fertigungshalle.avif"
     width="1200" height="800"
     alt="Blick in eine Fertigungshalle"
     loading="lazy">

img { max-width: 100%; height: auto; }

Beim Einwilligungsbanner für Cookies lohnt ein zweiter Blick. Es ist eine der häufigsten Ursachen für schlechte CLS-Werte, weil es spät geladen wird und den Inhalt darunter nach unten schiebt. Ein Banner mit fester Position über dem Inhalt statt im Textfluss löst das Problem, ohne dass an der Einwilligung selbst etwas geändert wird.

Der günstigste Zeitpunkt für all das ist ein Website-Relaunch. Bildformate, Schriftbindung und Skript-Bestand lassen sich dort in einem Zug klären.

Häufige Fehler

Nur im Labor messen. Werte vom eigenen schnellen Anschluss und aktuellen Rechner haben wenig mit den Felddaten zu tun, die tatsächlich in die Bewertung eingehen.

Auf hundert Punkte optimieren. Der Aufwand für die letzten Punkte im Lighthouse-Bericht steht in keinem Verhältnis zum Nutzen. Der gute Bereich reicht, und darüber hinaus zählt keine weitere Verbesserung für die Bewertung.

Bildmaße weglassen. Ohne Breite und Höhe im HTML kennt der Browser die Größe erst, wenn die Datei geladen ist. Bis dahin steht der Inhalt an der falschen Stelle.

Drittanbieter-Skripte sammeln. Jedes zusätzliche Werkzeug für Tracking, Chat oder Bewertungen kostet Reaktionsfähigkeit. Regelmäßiges Ausmisten wirkt mehr als jede Feinoptimierung am eigenen Code.

Sofort nach dem Livegang neu messen. Die Felddaten der Search Console decken 28 Tage ab. Eine Verbesserung von gestern ist dort erst Wochen später vollständig sichtbar.

Abgrenzung

Core Web Vitals sind nicht dasselbe wie Ladezeit im allgemeinen Sinn. Sie messen drei bestimmte Aspekte der Nutzererfahrung, nicht die Gesamtdauer bis zum vollständig geladenen Dokument. Eine Seite kann lange im Hintergrund nachladen und trotzdem alle drei Werte im guten Bereich haben.

Sie sind auch nicht der Punktwert aus Lighthouse. Dieser Wert entsteht im Labor aus mehreren Größen und enthält Kennzahlen, die nicht zu den Core Web Vitals gehören. Die Bewertung für die Suche stützt sich ausschließlich auf Felddaten.

Und sie sind kein eigenständiges Ranking-Update. Sichtbarkeitssprünge nach einem Core Update haben inhaltliche Ursachen und lassen sich nicht durch schnellere Ladezeiten zurückholen.