Google Core Web Vitals

Beitragsbild für den Beitrag über die Core Web Vitals

Google Core Web Vitals – der neue Rankingfaktor

Die Core Web Vitals werden von Google als wichtigster Indikator für die Page Experience einer Website herangezogen. Seit Juni 2021 werden die Core Web Vitals im Zuge des Page Experience Updates als Rankingfaktor für die mobile Suche angewendet. Die volle Auswirkung von diesem Update wird jedoch erst ab August 2021 erwartet.

Was sind die Core Web Vitals von Google?

Die Google Core Web Vitals bestehen aktuell aus drei Metriken, welche besonders wichtig für die Beurteilung der User Experience sind. Diese Kennzahlen geben Auskunft über die Ladezeit, die Reaktionsfreudigkeit sowie die visuelle Stabilität einer Website während dem Ladevorgang.

Die Google Core Web Vitals bestehen aus folgenden Kennzahlen:

Die Core Web Vitals sind jedoch nur ein Teil der kompletten Page Experience. Ebenfalls Bestandteile der Page Experience sind laut Google folgende Faktoren:

  • Mobilfreundlichkeit
  • HTTPS
  • Safe Browsing
  • keine störenden Interstitials
Bestandteile der Google Web Vitals
Bestandteile der Google Web Vitals

Largest Contentful Paint (LCP)

Der Largest Contentful Paint gibt Auskunft über die Ladezeit einer Website. Der LCP zeigt an, wie lange es dauert bis das größte Element einer Seite geladen ist.

Beispiel: Auf einer Website sind verschiedene Bilder mit unterschiedlichen Größen eingebunden. In diesem Fall würde der LCP angeben wie lange es dauert bis das größte Bild geladen ist.

Laut Google sollte der Largest Contentful Paint nicht mehr als 2500 Millisekunden betragen, damit dieser noch im grünen Bereich liegt.

Benchmarks für den Largest Contentful Paint (LCP)
Benchmarks für den LCP

Wie kann der Largest Contentful Paint (LCP) optimiert werden?

Der Largest Contentful Paint bezieht sich, wie bereits erwähnt, auf die Ladezeit einer Website. Alles was zur Verbesserung der Ladezeit unternommen wird, begünstig auch den LCP.

Top-Optimierungsmaßnahmen für den LCP:

  • hohe Antwortzeiten des Servers vermeiden – beispielsweise durch leistungsfähigere Hardware, Verwendung von CDNs oder durch das Caching von statischen Ressourcen
  • nicht benötigtes CSS und JavaScript entfernen
  • Bilder optimieren und komprimieren
  • wichtige Ressourcen mittels <link rel=“preload“> vorladen
  • Server-Side Rendering oder Pre-Rendering verwenden
  • kritisches CSS inline setzen
  • CSS, welches nicht sofort benötigt wird, asynchron nachladen
  • HTML-Seiten hauptsächlich aus dem Cache ausliefern
  • Verwendung von Adaptive-Serving: Ausspielung der Ressourcen an die verfügbare Bandbreite anpassen – bei langsamer Internetverbindung statt einem Video ein Bild ausspielen

Cumulative Layout Shift (CLS)

Der Cumulative Layout Shift wird als Kennzahl für unerwartete Verschiebungen des Layouts während dem Laden einer Website verwendet. Er wird durch das Summieren von Layoutverschiebungen in Session Windows gemessen. So werden Gruppierungen von mehreren Layoutverschiebungen genannt.

Beispiel: Plötzliche Layoutverschiebungen können auftreten, wenn Werbung nachgeladen wird oder Inhalte nachträglich per JavaScript hinzugefügt werden. Anbei befindet sich eine simulierte Layoutverschiebung am Beispiel der mobilen Zalando-Startseite.

Zalando-Startseite ohne Layoutverschiebung
Zalando-Startseite mit Layoutverschiebung

Unerwartete Layoutverschiebungen beeinträchtigen die User Experience, da sie zu nicht gewollten Klicks führen können. Wenn ein Button oder ein Link nach unten oder auf die Seite rutscht, kann es sein, dass Website-Besucher auf einen falschen Link oder Button klicken.

Laut Google sollte der CLS maximal 0,1 betragen, damit eine Website im grünen Bereich liegt. Aktuell erfüllen nur sehr wenige Websites diese Benchmark.

Wie kann der Cumulative Layout Shift (CLS) optimiert werden?

Der Cumulative Layout Shift ist die Kennzahl für unerwartete Layoutverschiebungen. Maßnahmen, welche die Stabilität einer Website beim Laden verbessern, begünstigen auch den CLS.

Top-Optimierungsmaßnahmen für den CLS:

  • alle Bilder mit Breiten- und Höhenangaben im HTML kennzeichnen
  • nachträgliches Einfügen von Inhalten mittels JavaScript vermeiden
  • Anzeigen, Iframes und weitere nachträglich geladene Inhalte mit Breiten- und Höhenangaben im Quellcode kennzeichnen
  • kritisches CSS vorab laden
  • Sofern Fonts nachgeladen werden, sollten diese mittels <link rel=“preload“> integriert werden

First Input Delay

Der First Input Delay gibt Auskunft über die Reaktionsgeschwindigkeit einer Website. Der FID misst die Dauer zwischen der ersten Interaktion des Nutzers (z.B. Klick auf einen Button) und dem Beginn der Verarbeitung der Nutzerinteraktion durch den Browser. Der First Input Delay ist die einzige Kennzahl, die sich nicht mit einem Tool messen lässt. Die Werte des FID können je nach Zeitpunkt und Art der ersten Interaktion unterschiedlich ausfallen.

Der First Input Delay sollte laut Google maximal 100 Millisekunden betragen.

Alternativ können statt dem FID auch die Laborwerte der Total Blocking Time (TBT) verwendet werden. Die Total Blocking Time gibt die Differenz zwischen dem First Contentful Paint (FCP) und der Time to Interactive (TTI) an. Das ist der Zeitpunkt zu welchem erste Inhalte bereits vom Browser angezeigt werden und dem Moment, ab dem der Browser auf Nutzerinteraktionen reagieren kann. Laut Google sollte die TBT nicht mehr als 300 Millisekunden dauern.

Benchmarks für den First Input Delay (FID)
Benchmarks für den First Input Delay (FID)

Wie kann der First Input Delay (FID) optimiert werden?

Wie erwähnt, bezieht sich der First Input Delay auf die Reaktionsgeschwindigkeit einer Website. Bereits die Aufteilung von umfangreicheren Tasks in kleinere Aufgaben, kann zur Verbesserung des FIDs führen.

Top-Optimierungsmaßnahmen für den FID:

  • umfangreiche JavaScript-Aufgaben in kleinere, asynchrone Tasks aufsplitten
  • kaskadierende Datenabrufe und die Abhängigkeit von diesen Requests vermeiden
  • Datenmenge, welche im Client verarbeitet werden muss, minimieren
  • Skripte von Third-Party-Ressourcen reduzieren bzw. nur bei Bedarf laden
  • wichtige Inhalte zu Beginn laden
  • Verwendung von Web Worker, um JavaScript im Hintergrund auszuführen
  • nicht benötigtes JavaScript entfernen
  • nicht genutzte Polyfills entfernen

Wie können die Core Web Vitals gemessen werden?

Für die Bestimmung der Core Web Vitals zieht Google reale Nutzerdaten heran, welche aus dem Chrome User Experience Report stammen. In diesem Report werden Daten gesammelt, die von den Browsern der Nutzer übertragen werden. Die Übertragung erfolgt nur nach ausdrücklicher Zustimmung.

Wer selbst testen möchte, ob die eigene Website im empfohlenen Bereich der Core Web Vitals liegt, kann dazu das Google PageSpeed Insights Tool verwenden. Google stellt hier neben Nutzerdaten auch Labordaten zur Verfügung. Die Labordaten sind jedoch nur Näherungswerte. Es sollte beachtet werden, dass nur die Nutzerdaten Auswirkungen auf das Ranking haben.

Messung der Core Web Vitals mit dem Head-Up-Display von Google Chrome

Wer selbst einen Live-Test durchführen möchte, kann dies mit Google Chrome ab Version 90 machen. Diese Version verfügt über ein Head-Up-Display, welches Werte für die Core Web Vitals der jeweiligen Website anzeigt.

Die Aktivierung des Head-Up-Display in Google Chrome (ab Version 90)

  • about:flags in die Browserleiste eintippen und laden
  • nach “show performance metrics in HUD“ suchen
  • show performance metrics in HUD von default auf enabled umstellen

Beginnen Sie jetzt die Core Web Vitals Ihrer Website zu optimieren, um bestens für das Google Page Experience Update vorbereitet zu sein. Wir helfen Ihnen gerne dabei!

Haben Sie noch Fragen?

Kontaktieren Sie uns: office@klickimpuls.at oder +43 5 0231

Das wird Sie auch interessieren …

Bilderweiterungen

Was sind Bilderweiterungen? Bilderweiterungen bieten die Möglichkeit, Textanzeigen um ein visuelles Asset zu erweitern...

Unverbindlich Anfragen

Standort Linz

Scharitzerstraße 2-4
4020 Linz
Österreich

Standort Wels

Zeileisstraße 6
4600 Wels
Österreich