Was sind die Core Web Vitals? Wie messen Ladezeit, Stabilität und Reaktionsschnelligkeit das Google-Ranking?

Die Seite lädt, der Text kommt, der Daumen tippt auf einen Button, und genau jetzt rutscht der Inhalt nach unten. Der Klick geht auf eine Anzeige. Jeder kennt solche Momente, der regelmäßig mobil surft. Google sammelt diese Erfahrungen systematisch und fasst sie in den Core Web Vitals. Drei Kennzahlen beschreiben, wie schnell Inhalte sichtbar werden, wie stabil das Layout bleibt und wie schnell eine Seite auf Eingaben reagiert. Sie gehören zu den Signalen der Page Experience und spielen damit für die Sichtbarkeit in der Suche eine Rolle.

Drei Kennzahlen mit definierten Grenzwerten

Der Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element im Sichtbereich der Seite fertig dargestellt ist, in der Regel ein Bild oder ein Textblock. Gut ist ein Wert bis 2,5 Sekunden. Die Interaction to Next Paint (INP) misst die Reaktionszeit auf Klicks, Taps und Tastatureingaben. Auch hier liegt der Wert bei 200 Millisekunden. Der Cumulative Layout Shift (CLS) beschreibt, wie stark sich Elemente beim Laden verschieben. Der Zielwert liegt bei maximal 0,1.

Alle drei Werte lassen sich objektiv messen, sodass sie zu Beginn vieler technischer Audits stehen, wie sie etwa eine SEO Agentur am Anfang jeder Optimierung durchführt. Inhaltliche Relevanz ist für das Ranking jedoch gewichtiger als gute Ladewerte. Entscheidend sind die Vitals also nur da, wo mehrere Seiten thematisch gleich stark sind.

Bewertet wird nicht der Einzelfall. Laut der Google-Dokumentation zu Web Vitals müssen Grenzwerte von mindestens 75 Prozent der Seitenaufrufe eingehalten werden, getrennt nach Mobil- und Desktopnutzung. Ein schneller Test an einem eigenen Rechner sagt also wenig über die Besucher eines Onlineshops aus, die noch ein älteres Gerät oder einen schwachen Mobilfunkanschluss haben.

Woran schlechte Werte typischerweise liegen

Meist steckt beim LCP ein zu großes Titelbild dahinter. Eine unkomprimierte JPEG-Datei mit mehreren Megabyte speckt die Darstellung einfach merklich ein. Besser geht es mit modernen Formaten wie WebP oder AVIF, die bei vergleichbarer Qualität die Datenmenge deutlich reduzieren. Langsame Serverantworten, fehlendes Caching und Stylesheets oder Skripte, die die Darstellung blockieren, kommen dazu.

Für die INP ist meistens zu viel JavaScript schuld. Tracker, Chat-Widgets und Werbebausteine von Drittanbietern belegen den Hauptthread des Browsers, auf den das Eingeben der Suchanfrage wartet. Länger als 50 Millisekunden dauernde Aufgaben sind dabei schon ein Warnsignal.

Steigen wird der CLS, wenn Bilder ohne Breiten- und Höhenangabe eingebaut werden. Nachladende Werbung und Webfonts, die beim Tauschen die Schriftgröße verändern, bringen ebenfalls Inhalte zum Verschieben. Der Browser hat dann nichts reserviert, und der Text rutscht.

Schritte in die Praxis

Wer etwas tun möchte, kann sich an dieser Reihenfolge orientieren:

  • Bilder komprimieren, im passenden Format ausliefern und mit Größenangaben versehen
  • Nicht benötigte Skripte eliminieren und Code von Drittanbietern verzögert laden
  • Caching aktivieren und bei internationalem Publikum ein Content Delivery Network nutzen
  • Schriften lokal einbinden und für Werbeflächen feste Plätze reservieren
  • Nach jeder Änderung neu messen, da die Felddaten über einen Zeitraum von 28 Tagen gesammelt werden

Der erste Blick gehört der Search Console, denn dort wird sichtbar, welche Seitentypen betroffen sind. Danach am besten die Vorlagen angreifen, die am meisten Aufrufe haben. Eine Korrektur an einem Template wirkt sich oft auf Hunderte von Seiten gleichzeitig aus.

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert