Core Web Vitals: Neuer Rankingfaktor bei Google

Ab Juni 2021 ist es soweit. Google macht die User Experience auf Websites zum Rankingfaktor. Wer jetzt noch immer keine Vorstellung davon hat, was LCP, FID und CLS bedeuten, findet hier einen Schnelleinstieg inklusive vieler Tipps zur Optimierung der Core Web Vitals.

Google Page Experience Update

Im Rahmen des Page Experience Updates führt Google mit den Core Web Vitals neue Kennzahlen ein, mit denen die Nutzererfahrung bzw. die Nutzerfreundlichkeit einer Seite gemessen werden kann.

Google möchte seinen Nutzern jederzeit die besten Antworten auf ihre Suchanfragen liefern. Da die Antworten, also die Suchergebnisse, nicht aus einem eigenen Ökosystem stammen, sondern aus externen Quellen, hat Google keinen direkten Einfluss auf die Nutzererfahrung auf den externen Seiten.

Wenn Du ein Restaurant empfiehlst, möchtest Du am Ende auch nicht die Resonanz erhalten, dass es dort schmutzig und die Bedienung unhöflich war.

Die Core Web Vitals Metriken mit Erklärung

Die Core Web Vitals bestehen aus drei ranking-relevanten Metriken. Dem Largest Contentful Paint (LCP), dem First Input Delay (FID) und dem Cumulative Layout Shift (CLS).

Was ist der Largest Contentful Paint?

Der Largest Contentful Paint gibt an, wie lange es dauert, bis der Hauptinhalt (das größte Element) im sichtbaren Bereich der Seite geladen/gerendert ist. Das endgültige LCP Element steht daher erst am Ende des Ladevorgangs fest. Wer die Werte seines LCP misst, muss darauf achten, dass nur das jeweils letzte LCP Element getrackt wird. 

Mögliche LCP Elemente sind dabei ab Juni 2021:

• Bilder (<img>-Elemente)
• <image>-Elemente innerhalb eines <svg>-Elements
• Das Poster (Vorschaubild) innerhalb eines <video>-Elements
• Textblöcke
• Elemente wie div-Container mit einem CSS-Hintergrundbild

Nach einer Eingewöhnungsphase behält sich Google vor, diese gegebenenfalls zu ergänzen. Zum Beispiel um <video> und <svg>.

Entscheidend ist nicht die Elementgröße, sondern wieviel des Elements im sichtbaren Bereich liegt. Ein Beispiel:

Das rote Rechteck, in der Grafik oben, ist wesentlich größer als das Grüne. Der Teil des roten Rechtecks, welcher sich im sichtbaren Bereich befindet, ist allerdings kleiner, als der des grünen Rechtecks. Somit ist das grüne Rechteck der Hauptinhalt (Largest Contentful Paint).

Bei Textelementen wird nur die Größe ihrer Textknoten berücksichtigt (das kleinste Rechteck, dass alle Textknoten umschließt). Außen- und Innenabstände von Elementen (margin und padding) zählen nicht zu der Elementgröße! 

Das Wort “largest” bezieht sich nicht auf die Dateigröße (KB oder MB), sondern auf die Fläche, die ein Element im initialen Viewport einnimmt.

Ein Bild mit 800 x 800 Pixeln herunterskaliert zu 100 x 100 Pixeln hat eine Größe von 100 x 100 Pixeln. Ein Bild mit 30 KB und den Maßen 600 x 600 Pixeln ist also größer als ein Bild mit 100 KB und 50 x 50 Pixeln. Bei herunterskalierten Bildern sind daher die herunterskalierten Dimensionen entscheidend.

Zu Beginn werden nachträglich wieder entfernte Elemente nicht mehr für den LCP berücksichtigt. Google hat aber schon jetzt angekündigt, dies zukünftig wahrscheinlich zu ändern. 

Der Largest Contentful Paint liegt idealerweise unter 2,5 Sekunden. 

Was ist der First Input Delay?

Der First Input Delay misst die Verzögerung zwischen einer Benutzeraktion (zum Beispiel: Klick auf einen Button) und den Beginn der Bearbeitung dieser durch den Browser (nicht die Dauer der Bearbeitungszeit selbst). 

Wenn eine Seite aufgerufen wird, sendet der Server das HTML-Dokument. Die dort verlinkten Stylesheets, JavaScript-Dateien, Bilder etc. werden vom Browser ebenfalls angefragt und heruntergeladen (graue Balken). Anschließend führt der Browser die Style- und Javascript-Anweisungen aus und ist mit dem Rendering der Seite beschäftigt (gelbe Balken). Wenn der Main Thread des Browsers z.B. mit dem Rendern der Seite beschäftigt ist und zeitgleich eine Nutzeraktion stattfindet, kann der Browser nicht darauf reagieren, da der Main Thread bereits ausgelastet ist. 

Der First Input Delay liegt idealerweise unter 100 Millisekunden.

Was ist der Cumulative Layout Shift?

Der Cumulative Layout Shift gibt Aufschluss darüber, wie stabil das Seitenlayout während des Seitenbesuches ist. Er ist die Summe aller unerwarteten Layout-Verschiebungen.  

Ein Beispiel für einen solchen unerwarteten Layout-Shift sind Seiteninhalte, die sich nach unten verschieben, weil oberhalb der Seite ein Anzeigen-Banner nachgeladen wird. 

In der Grafik sehen wir einen Ladevorgang heruntergebrochen auf drei Frames. Im ersten Frame links sind bereits erste Elemente geladen. So sehen wir beispielsweise Text (hier blau und schwarz dargestellt) und ein Bild in der Farbe grün. Im zweiten Frame (mittlere Darstellung) wird ein weiteres Element z.B. ein Slider nachgeladen (hier rot dargestellt) und verschiebt bereits vorhandene Elemente nach unten. Im letzten Frame wird das komplette bis dahin geladene Layout noch einmal unerwartet nach unten verschoben, weil ein Werbebanner nachträglich an den Seitenanfang gerendert wurde.

Der CLS Score liegt idealerweise unter 0,1. 

Wie wird der Cumulative Layout Shift berechnet?

Um zu verstehen, wie der Cumulative Layout Shift Score berechnet wird, schauen wir uns ein weiteres Beispiel an.

Die unerwartete Layout-Verschiebung

Diese Grafik zeigt den Ladevorgang einer Produktseite eines Online-Shops. In den ersten 3 Frames kommt es zu keiner Layout-Verschiebung. Im vierten Frame wird ein Element nachträglich an den Seitenanfang, oberhalb des bereits vorhandenen Contents geladen, was dazu führt, dass bereits vorhandener Content unerwartet nach unten verschoben wird. 

Um den CLS Score zu berechnen, schauen wir im ersten Schritt, wie viel des Layouts (im sichtbaren Bereich) betroffen ist. Das sind in diesem Beispiel 90 % des Viewports (Impact Fraction). Im zweiten Schritt schauen wir, um wie viel Prozent das Layout verschoben wird (Distance Fraction). 

Layout Shift Score = Impact Fraction x Distance Fraction

0,108 = 0,9 x 0,12

Kommt es im Verlauf des Seitenbesuchs zu weiteren unerwarteten Verschiebungen des Layouts, werden die einzelnen Scores miteinander addiert, wie der Name Cumulative Layout Shift schon sagt.

Das Problem dabei ist, dass lange, inhaltsstarke Seiten, wie zum Beispiel One Pager, nach diesem Modell tendenziell benachteiligt werden. Denn hier können im Verlauf des Seitenbesuchs deutlich mehr Layout-Verschiebungen stattfinden, als auf kurzen, inhaltsarmen Seiten.

Cumulative Layout Shift, das Modell Session Windows

Um eine derartige Benachteiligung zu vermeiden, werden Verschiebungen des Layouts zukünftig während des Seitenbesuchs in Session Windows aufgeteilt („maximum session window with 1 second gap, capped at 5 seconds“).

Mit der ersten Layout-Verschiebung wird ein Session Window gestartet, welches durch einen Session Gap wieder geschlossen wird.

Schauen wir uns dazu die Grafik oben an. Die horizontale Linie ist dabei der Zeitstrahl unseres Seitenbesuchs. Die blauen Balken stehen jeweils für eine Layout-Verschiebung. Je stärker die Verschiebung des Layouts, desto höher der Balken.

Mit dem ersten Balken (Layout Shift) wird ein Session Window gestartet (Session Window 1). Es folgen zwei weitere Balken und dann ein Session Gap (eine Lücke von mindestens einer Sekunde ohne Layout-Verschiebungen). Wie bereits erwähnt, schließt der Session Gap das Session Window 1.

Mit dem nächsten Layout Shift wird ein neues Session Window (Session Window 2) gestartet.

Ein Session Window ist also eine Gruppierung von Layout-Verschiebungen. Die einzelnen CLS Scores werden pro Session Window addiert und nur das Session Window mit dem höchsten CLS Score bestimmt dann den Cumulative Layout Shift Score der Seite.

Durch die Begrenzung der Länge der Session Windows auf fünf Sekunden, soll vermieden werden, dass langsame Websites bevorteilt und Seiten mit fortlaufenden, kleinen Layout-Verschiebungen (zum Beispiel stetig aktualisierender Newsticker zu Sportereignissen) unverhältnismäßig benachteiligt werden.

Die erwartete Layoutverschiebung

Doch was ist, wenn sich das Layout aufgrund einer User Interaktion verschiebt, weil beispielsweise ein Akkordeon ausgeklappt wird? 

Verschiebt sich das Layout aufgrund eines Nutzer Inputs, wird die Verschiebung nicht auf den CLS Score addiert, wenn die Verschiebung innerhalb von 500 Millisekunden abgeschlossen ist. 

Achtung: Scrollen und Zoomen sind keine Nutzer-Aktionen, die zu einem erwarteten Layout Shift führen. Vermeide daher Layout-Verschiebungen bei diesen Aktionen! 

Wie werden die Core Web Vitals gemessen?

Bei der Messung der Core Web Vitals unterscheiden wir grundsätzlich zwischen Labordaten und Felddaten. 

Bei den Felddaten handelt es sich um echte Nutzerdaten (Chrome-Browser). Diese Daten werden ab Juni 2021 als neuer Rankingfaktor einen Einfluss auf die Suchergebnisse haben. Wie stark die Core Web Vitals am Anfang gewichtet werden und welchen Einfluss sie auf die Rankings haben, ist aktuell nicht bekannt. 

Bei den Labordaten handelt es sich um Messdaten, die unter immer gleichen Bedingungen simuliert werden. Daher sind Labordaten besonders interessant, wenn man Optimierungen an der Seite vornimmt und die Auswirkungen direkt testen möchte.

Da bei simulierten Messungen kein Nutzer Input stattfindet, kann der First Input Delay nicht ermittelt werden. Als guter Ersatzwert kann hier die TBT (Total Blocking Time) herangezogen werden. 

Wer seine Webseite direkt testen möchte, kann beispielsweise auf das kostenlose Tool von Google, PageSpeed insights, zurückgreifen. Neben den Felddaten und den Labordaten zeigt das Tool auch auf, ob die Seite in den letzten 28 Tagen anhand echter Nutzerdaten den Core Web Vitals Test bestanden hat. Darüber hinaus listet das Tool sowohl erkannte Probleme als auch Optimierungsmöglichkeiten auf. 

Wie sind die Testergebnisse zu werten?

Sofern für die getestete URL ausreichend echte Nutzerdaten zur Verfügung stehen, kann man im oberen Bereich unter Felddaten einsehen, ob die getestete Seite den Core Web Vitals Test anhand der Daten der letzten 28 Tagen bestanden hat.

Die relevanten Messwerte lassen sich leicht finden, da die Core Web Vitals Metriken mit einem blauen Fähnchen hervorgehoben werden.

Schauen wir uns das ganze einmal am Beispiel des First Input Delays an:

Neben dem FID sehen wir den Wert 71 Millisekunden. Dabei handelt es sich nicht um den Durchschnitt, sondern um einen aggregierten Wert, der auf dem 75. Perzentil der gemessenen Nutzerdaten der letzten 28 Tage, für diese URL beruht. Das heißt, dass 75 Prozent der Nutzer in den letzten 28 Tagen, die diese URL aufgerufen haben, einen First Input Delay von 71 Millisekunden oder besser hatten. 

Der Skala direkt darunter kann entnommen werden, dass 82% der Nutzer, in den letzten 28 Tagen, einen guten FID Wert für die getestete Seite hatten (weniger als 100 Millisekunden).

14 % der Nutzer hatten einen verbesserungswürdigen FID (100 bis 300 Millisekunden).

4 % der Nutzer hatten einen schlechten FID von mehr als 300 Millisekunden.

Tipp: Prüfe immer mehrere Seiten (URLs) deiner Website, nicht nur die Startseite. Um eine optimale Übersicht zu erhalten gruppierst Du deine Website am besten nach ähnlichem Aufbau. Bei einem Shop sind dies häufig Kategorieseite, Produktseite und Blog. 

Was verursacht den Layout Shift bei mir?

Um herauszufinden welche Seiteninhalte sich unerwartet verschieben, kann man die DevTools vom Chrome Browser zur Hilfe nehmen. Dazu einfach im Chrome auf der gewünschten Seite die Tastenkombination Strg + Umschalt + i drücken und dann den Reiter “Performance” auswählen:

Beginnen wir oben links:

1. Über den Device Emulator (blau hervorgehoben, siehe Pfeil 1) wählen wir ein Mobilgerät, für welches wir testen möchten. 
2. Anschließend wählen wir den Reiter Performance, sofern noch nicht geschehen (Pfeil 2).
3. Danach setzen wir einen Haken bei „Screenshots“ und optional bei „Web Vitals“ (Pfeil 3).
4. Über den „reload button“ (Pfeil 4) zeichnen wir den Page Load automatisch auf.
5.  Über den „record button“ kann alternativ eine manuelle Aufzeichnung gestartet werden (Pfeil 5). 

Wenn der Reload abgeschlossen ist, sieht das Ganze in etwa so aus: 

In der Zeile “Experience” werden alle Layout-Verschiebungen als roter Balken angezeigt. Um zu erkennen, welches Element betroffen ist, kann mit der Maus über den Balken gefahren werden. Das betroffene Element wird dann farblich markiert.

Unter “Summary” können weitere Details des CLS eingesehen werden:

Die Angabe “Had recent input” zeigt an, ob es sich um einen unerwarteten Layout Shift oder einen, durch Nutzer-Input, erwarteten Layout Shift handelt. Hat sich das Layout verschoben, weil es durch eine Nutzeraktion ausgelöst wurde, steht dort “Yes”. In dem Fall ist alles in Ordnung und die Verschiebung wird nicht auf den Cumulative Layout Shift Score addiert.

Tipp: Will man für eine bestimmte Nutzeraktion prüfen, ob die Verschiebung des Layouts auf Grund eines Nutzerinputs korrekt erkannt wird, kann der Record-Button (siehe Abbildung oben bei „Was verursacht den Layout Shift bei mir?“) genutzt werden. Führt man während der Aufnahme die Nutzeraktion durch, kann sie im Anschluss in den DevTools begutachtet werden.

Die Angabe unter “Related Node” ist nicht in allen Fällen sonderlich aufschlussreich, kann häufig aber einen Hinweis auf das Element geben, welches verschoben wurde. 

Wie können die Core Web Vitals optimiert werden?

Wie bereits erwähnt, gibt das Tool PageSpeed Insights häufig schon relevante Verbesserungsvorschläge. Darüber hinaus gebe ich dir noch ein paar allgemeine Empfehlungen zur Verbesserung der Core Web Vitals mit.

Den Largest Contentful Paint verbessern

Damit der Hauptinhalt einer Seite so schnell wie möglich dargestellt werden kann, ist es im ersten Schritt wichtig, dass der Server eine schnelle Reaktionszeit hat. Dateien, wie Stylesheets, JavaScripts und Bilder, die zur Darstellung benötigt und vom Browser heruntergeladen und ausgeführt werden müssen, sollten möglichst klein gehalten werden.

Inhalte, die das Rendern blockieren (häufig eingebundener Code von Drittanbietern), sind ebenfalls zu vermeiden. Wer fünf Trackingdienste eingebunden hat und nur zwei nutzt, kann drei entfernen.

• Für eine schnelle Serverantwortzeit sorgen (TTFB)
• CSS und Skripte minimieren und ungenutztes CSS und Skripte ggf. entfernen
• Bilder immer komprimieren
• Mehrere Bildinstanzen für unterschiedliche Viewports verwenden
• Nicht unbedingt benötigte Erweiterungen/Plugins oder Drittcode entfernen
• Weiterleitungsketten vermeiden
• Sicherstellen, dass Text beim Laden von Schriftarten (Webfonts) sichtbar bleibt
• Statische Inhalte mit einer effizienten Cache-Richtlinie bereitstellen

Wer noch mehr Details haben möchte, wird in Googles Blogartikel fündig.

Wie kann der First Input Delay verbessert werden?

Um den FID möglichst kurz zu halten, gelten grundsätzlich auch die Optimierungsmaßnahmen für den Largest Contentful Paint (siehe oben).

Hinzu kommen:

• Reduzieren der Ausführungszeit von JavaScripts
• Lange Tasks, die den Main Thread länger als 50 Millisekunden blockieren, in kleinere, asynchrone Tasks aufsplitten.  

Auch hier gibt es einen detaillierten Beitrag von Google.

Einen hohen Cumulative Layout Shift vermeiden

• Niemals Inhalte oberhalb bereits vorhandener Inhalte nachladen (sofern dafür nicht vorab bereits ein Platzhalter vorhanden war)
• Keine Animationen verwenden, die das Layout unerwartet verschieben
• Immer size-Attribute für Bild- und Videoelemente verwenden oder einen Platzhalter mit dem passenden Seitenverhältnis verwenden (siehe dazu CSS aspect ratio boxes)
• Sicherstellen, dass Layoutverschiebungen nach einem Nutzerinput innerhalb von 500 Millisekunden (inklusive Animation) abgeschlossen sind.
• Sicherstellen, dass nachgeladene Schriftarten nicht zu einer Verschiebung des Layouts führen

Zur Optimierung des Cumulative Layout Shifts gibt es natürlich ebenfalls einen ausführlichen Artikel.

Fazit zu den Core Web Vitals

PageSpeed und User Experience sind keine neuen Begriffe und deren Optimierungen keine Zauberei. Maßnahmen zur Optimierung von Largest Contentful Paint und First Input Delay werden schon seit geraumer Zeit von SEOs unter dem Gesichtspunkt der Ladezeitenoptimierung empfohlen. Neu ist lediglich, dass wir jetzt, mit den zwei Metriken LCP und FID, einen einheitlichen Standard für die Mindestanforderungen haben. 

Da sich das Einhalten der Mindestanforderungen ab Juni 2021 auf die Rankings auswirken kann, sollte spätestens jetzt genügend Motivation vorhanden sein, die Empfehlungen aus der SEO-Abteilung umzusetzen.

Mit dem Cumulative Layout Shift haben wir nun auch ganz offiziell eine Metrik für die User Experience, beziehungsweise eine Argumentationshilfe für eine gewisse Mindestanforderung an die Stabilität des Layouts einer Website. Und das dürfte sich letztendlich bei vielen auch positiv auf die Conversion Rate auswirken.

Konntet Ihr eure Core Web Vitals schon “in den Griff” kriegen? Falls nicht, schreibt uns gerne eure Fragen.

Patrick

Kostenlose Online-Marketing-Webinare

Wir bieten jede Woche kostenlos zwei Webinare an. Alle Themen und die nächsten Termine findet ihr auf: web-netz.de/webinare.

Bildnachweis Titelbild: Photo by Rajeshwar Bachu on Unsplash / web-netz

Bildnachweis Grafiken: Sofern kein anderer Bildnachweis angegeben ist, stammen die Grafiken von web-netz.