Selten zuvor hat Google ein Update des Rankingalgorithmus mit so viel Vorlauf angekündigt. 2021 wird das neue Page-Experience-Update kommen, wobei Website-Betreiber und Entwickler schon jetzt mit den neuen Metriken arbeiten können. Im Kern geht es dabei um die Nutzerfreundlichkeit und das Ladeverhalten von Webseiten – und nicht allein um die Ladegeschwindigkeit. Die lange Vorbereitungszeit, die Google für das Page-Experience-Update ermöglicht, deutet an, wie wichtig es ist.
Googles Ankündigung, 2021 das Experience-Update durchzuführen, hat Websites, SEOs und Entwickler aufhorchen lassen. Schließlich ist es unüblich, dass Google ein Update mit so großem Vorlauf ankündigt. Eine längere Vorbereitung und Planung gab es wohl nur im Zuge der Mobile-Optimierung von Websites und der Umstellung auf Mobile First. Googles Botschaft bei der neuerlichen Ankündigung ist klar: Die Umstellung ist wichtig. Website-Betreiber bekommen aber auch Zeit zur Vorbereitung sowie die nötige Transparenz, um den Handlungsbedarf einzuschätzen.
Mit der Einführung des Performance-Mess-Tools CoreWeb Vitals und der dazugehörigen Metriken LCP, FID und CLS gibt Google zu verstehen, in welcher Webdisziplin der Rankingalgorithmus verbessert werden soll: bei der User Experience (UX). Dieser Entwicklung sollten alle Seitenbetreiber, die sich auch in Zukunft behaupten wollen, Aufmerksamkeit schenken.
Vorweg sei gesagt, dass Content King bleibt, wenn es darum geht, Nutzern die relevantesten Inhalte bereitzustellen. Daneben bekommt aber die Nutzerfreundlichkeit von Websites mehr Gewicht. In Zukunft dürfte es darum kaum mehr ausreichen, nur auf Inhalte zu setzen. Das dürfte besonders für kompetitive Segmente gelten, wo die Relevanz der Inhalte und Webangebote bei einer Vielzahl von Websites gegeben ist. Vor allem in diesem Bereich will Google Nutzern durch die neuen Metriken das beste Angebot bereitstellen.
Google wies schon in der Vergangenheit immer wieder darauf hin, dass die Page Experience – oder auch User Experience – mitentscheidend dafür ist, ob den Besuchern eine Seite gefällt. Um das nachzuvollziehen, muss man kein UX-Experte sein. Werden Inhalte auf dem Smartphone beispielsweise nicht responsiv und damit viel zu klein dargestellt, verabschieden sich viele Nutzer. Ähnlich sieht es aus, wenn mehrere Sekunden vergehen, ehe der Seitenaufbau so weit abgeschlossen ist, dass Nutzer etwas mit der Seite anfangen können. SEOs werden an dieser Stelle wissen, dass derartige Faktoren im Ranking bereits berücksichtigt werden. Mobile Friendliness und PageSpeed sind hier die Stichworte.
Definition: Die User Experience wird dadurch bestimmt, wie Nutzer Interfaces (etwa Webseiten) wahrnehmen und mit diesen interagieren.
Allerdings geht UX als Webdisziplin weit über Ladegeschwindigkeit und Mobile-Optimierung hinaus. Es handelt sich um ein weites Feld, in dem neben dem Ladeverhalten der Seite auch das Layout und die Interaktivität (Wie kann der Nutzer mit einer Seite interagieren?) eine Rolle spielen. Mit den neuen Metriken zeigt Google, dass die User Experience als zentraler Erfolgsfaktor von Websites besser einbezogen werden soll als bisher.
Für SEOs bedeutet es, dass sie diese Disziplin besser verstehen müssen, um auf die neuen Ranking-Metriken reagieren zu können. Ein Verständnis für die neuen Metriken bekommt man ehesten, wenn man sich anschaut, wie Google bisher die Page Experience einer Seite bewertete.
Um zu verstehen, wie die neuen Metriken funktionieren, sollten diese in den Kontext der bereits bestehenden Metriken eingeordnet werden.
Hier versuchte Google in den letzten Jahren nicht nur, die Betreiber zu schnelleren Websites zu bewegen, sondern entwickelte ganz detailliert Scores bzw. Metriken für das initiale Laden von Inhalten, das Laden von relevantem Content und die Interaktionsfähigkeit einer Seite. Diese Mittel sollen helfen, die Nutzung einer Website für User so reibungslos wie möglich zu machen. Bisher ließen sich die Metriken in Bereiche einteilen, die prüfen, ob und wie schnell Content geladen wird (Time to First Byte, First Paint, First Contentful Paint), ob der Content relevant oder sinnvoll ist (First Meaningful Paint, Speed Index, Visually Complete), ob eine Interaktion mit dem Content möglich ist (Time to Interactive, Total Blocking Time) oder ob die Interaktion flüssig ist (Frame Rate).
Vor allem in den letzten drei Bereichen gab es aber immer wieder Schwierigkeiten, genau zu definieren, was sich hinter einer Metrik verbirgt. Dies erkannte Google besonders beim Laden von bedeutungsvollem Content. First Contentful Paint, First Meaningful Paint und Time to Interactive sollten das Laden einer Webseite beschreiben. Nach zwei Jahren bemerkte jedoch Googles Entwicklerteam, dass vor allem der First Meaningful Paint schwer nachzuverfolgen und überdies durch kleinere Schwankungen im Rendering stark beeinflussbar war. Der Wert entsprach nicht Googles eigenen Vorgaben, war nicht flexibel und simpel genug.
Diesen Metrik-Problemen soll mit den neuen Core Web Vitals ein Ende gesetzt werden. Doch was genau verbirgt sich hinter ihnen?
Der First Meaningful Paint (FMP) war Teil mehrerer Metriken, um den Ladeprozess einer Website über Zahlen abbildbar zu machen (Abbildung 1).
Es stellte sich jedoch heraus, dass dieser im mittleren Ladeprozess angesetzte Wert starken Schwankungen unterlag und daher nicht repräsentativ war. Zudem war er schwer zu optimieren. Seitenverantwortliche hatten damit also nur eingeschränkte Mittel zur Hand, um innerhalb des Mid Loads den Ladeprozess zu verbessern.
Um jedoch auch weiterhin einen Wert bereitzustellen, der neben dem First Contentful Paint und der Time to Interactive bestehen kann, wurde nach einer neuen Metrik gesucht, die messbar macht, was in diesem Zeitabschnitt passiert. Naheliegend ist es, ein spezifisches Content-Element auszuwählen und dessen Render-Zeit zu betrachten. Googles konkrete Herangehensweise ist dabei denkbar simpel gehalten.
Der Largest Contentful Paint (LCP) bezeichnet die Render-Zeit des größten Elements, das im Viewport sichtbar ist. Paul Irish, Entwickler im Lighthouse- und Chrome-Developer-Team, definierte auf der Online-Konferenz #PerfMatters 2020 den LCP als „die Render-Zeit des größten Content-Elements im sichtbaren Bereich einer Webseite (Viewport)“.
So simpel die Definition ist – bei näherer Betrachtung stellen sich drei wichtige Fragen: 1. Was wird als Content-Element betrachtet? 2. Was ist überhaupt das größte Element? 3. Was verbirgt sich hinter der Render-Zeit?
Zu 1.: Für Google sind Bilder, Videos und Text Content. Dabei werden sowohl Vordergrund-Bilder (<img>, <image>) als auch für den Hintergrund geladene Bilder einbezogen. Videoelemente erfasst Google inklusive der Vorschaubilder und möglichem Text.
Zu 2.: Zur Messung des größten Elements auf einer Seite wird wie zuvor die Größe durch Breite * Höhe bestimmt, wobei Margin, Padding und Border nicht beachtet werden. Für verkleinerte Bilder wird der kleinere Wert, für vergrößerte Bilder ebenso der kleinere Wert und für Bilder, die nur teilweise im Viewport sichtbar sind, der sichtbare Teil berechnet (siehe Abbildung 2).
Zu 3.: Die Render-Zeit der oben beschriebenen Content-Elemente wird für Textelemente durch das Zeichnen der ersten Schrift berechnet. Sollte eine später nachgeladene Schrift den Text neu laden, zählt hier nur das erste Laden. Bei Bildern wie auch Videos kommt es auf die Herkunft an. Bei Bildern oder Videos gleicher Herkunft wird die Zeit der Zeichnung des Bildes oder des Videos nach dem Onload-Event herangezogen. Bei denjenigen unterschiedlicher Herkunft wird der sogenannte Timing-Allow-Origin-Header herangezogen, sofern dieser vorhanden ist. Sollte dieser Header bei der betreffenden Webseite nicht verfügbar sein, wird wie bei Bildern oder Videos gleicher Herkunft verfahren.
Sobald der User klickt oder in einer anderen Form mit der Seite interagiert, wird die Bewertung des LCP nicht mehr fortgeführt. Vorher findet sie durchgängig statt, d. h., jedes Element, das im Ladeprozess geladen wird, wird neu gewertet. Der Stopp nach dem Klicken oder Scrollen wird notwendig, da mit der Metrik nur der erste Eindruck innerhalb der User Experience gewertet werden soll.
Außerdem gehen Elemente, die auf dynamischen Webseiten aus dem Document Object Model (DOM) der HTML- bzw. XML-Dokumente entfernt werden, nicht in die Metrik ein. Wie aber mit Inhalten, die in einem Karussell liegen, umgegangen werden soll, ist Google selbst noch unklar. Updates sollen folgen.
Aus Google-Sicht ist eine LCP-Ladezeit bis zu 2,5 Sekunden angemessen. Optimierungsbedarf besteht spätestens dann, wenn die Ladezeit bei über 4 Sekunden liegt. Es sei nochmals daran erinnert, dass Googles Richtwerte auf Studien beruhen, die zeigen, wann Nutzer eine Seite verlassen bzw. keine weiteren Interaktionen durchführen.
Neben der reinen Ladezeit einer Seite will Google mit den neuen Werten vor allem die Interaktionsfähigkeit einer Seite metrisch darstellen. Schließlich steht genau dies im Mittelpunkt moderner Webseiten: die Interaktion des Nutzers mit der Seite. Diese Facette der User Experience sollen der First Input Delay (FID) und der Cumulative Layout Shift (CLS) bewerten.
Der First Input Delay nimmt dabei ein Problem in den Fokus, das viele User zum Abbruch einer Seite zwingt: Man glaubt, per Klick oder Push eine Interaktion auszuführen, doch die Seite reagiert nicht. Aus Nutzersicht bedeutet dies eine erhebliche Störung innerhalb der Journey. Das, was ins Sichtfeld rückt, sollte intuitiv die Customer Journey vorantreiben und nicht als Sackgasse wahrgenommen werden. Auch mit dieser Metrik versucht Google, den Eindruck zu erfassen, der in der initialen Phase der Page Experience entsteht.
Der First Input Delay stellt den Zeitraum zwischen der ersten Interaktion des Nutzers und dem Ausführen des Events im Browser dar. Der Wert gibt also an, ob und wie lange der Browser eventuell mit dem Parsen oder Ausführen von Dateien (beispielsweise großer JavaScript-Dateien) beschäftigt ist. Er schließt damit unmittelbar an den oben beschriebenen LCP an und wird, wie später zu sehen sein wird, von der Time to Interactive abgelöst (bis also die ganze Seite benutzt werden kann).
Für den First Input Delay werden also Events wie Klicks, Taps oder Tastendrücke zeitlich gemessen. Scrolling oder Zoomen werden nicht beachtet. Der FID wird im Ladeprozess der Seite berechnet, da hier meist schon die erste Interaktion mit der Seite passiert. Nur wenige Nutzer warten, bis eine Webseite vollständig geladen ist. Diese Zeit zu messen hilft auch, spätere Maßnahmen umzusetzen, da im Ladeprozess anders optimiert werden muss als nach dem vollständigen Laden einer Seite.
Schematisch ordnet sich der FID in den Ladeverlauf einer Webseite ein, wie in Abbildung 4 zu sehen ist.
Der Browser stellt über den gesamten Ladeprozess hinweg Netzwerkanfragen (graue Balken) für Ressourcen wie JavaScript, CSS oder Bilddateien. Sobald diese heruntergeladen wurden, können sie im Main Thread ausgeführt werden (beigefarbene Balken, Abbildung 4). In dieser Zeit ist der Main Thread ausgelastet. Diese Auslastung des Main Threads ist die wesentliche Ursache dafür, dass dynamische Interaktionen verzögert ausgeführt werden. Die Seite reagiert auf den „ersten Input“ des Nutzers erst nach der Ausführung der Aufgabe im Main Thread. Es kommt zu einer Verzögerung.
Um die Auswertung nicht zu verzerren, schlägt Google Folgendes vor: „While choice of percentile for all Core Web Vitals thresholds is the 75th, for FID in particular we still strongly recommend looking at the 95th–99th percentiles, as those will correspond to the particularly bad first experiences users are having with your site. And it will show you the areas that need the most improvement.“
Ist dies geschehen, werden Werte unter 100 ms als gut erkannt (Abbildung 5).
Für viele ist das Problem bekannt: Die Elemente einer Webseite verändern sich im Verlauf des Ladeprozesses. Während ein Button in einem Augenblick noch an der einen Position ist, springt er im nächsten an eine andere. Das Ergebnis ist, dass Nutzer auf nicht gewollte Seiten gelangen – aus deren Sicht eine frustrierende Erfahrung. Das kann nicht nur negative Folgen für die zentralen Werte wie Conversions, Verweildauer oder die Absprungrate haben, auch die Reputation einer ganzen Domain oder Brand kann darunter leiden.
Dieses Problem ist insbesondere im mobilen Web verbreitet. Denn auf vielen Geräten vollziehen sich bedingt durch die Displaygröße oder nachträglich eingeführte Inhalte für den Nutzer unerwartete Verschiebungen auf einer Webseite. Der Cumulative Layout Shift (CLS) soll als Metrik diesem Problem entgegenwirken.
Allgemein beschrieben fragt der CLS Seiten daraufhin ab, ob und um wie viel sich der Content im Verlauf des Ladeprozesses bewegt. Es handelt sich also um eine Metrik, die die Stabilität des Layouts einer Seite bewertet. Dabei handelt es sich ausschließlich um Bewegungen des Layouts, die nicht von den Nutzern intendiert sind und sich für diese unerwartet vollziehen.
Um Verschiebungen messbar zu machen, werden verschiedene Segmente innerhalb des Viewports zueinander in Beziehung gesetzt. Dazu wird der sogenannte Layout Shift Score (LSS) errechnet:
Layout Shift Score = Impact Fraction * Distance Fraction
Die Impact Fraction gibt an, welchen Anteil der Bereich, der von der Bewegung des Content-Elements zwischen zwei Frames betroffen ist (Impact Region), am gesamten Viewport ausmacht.
Die Distance Fraction gibt an, um wie viele Pixel sich ein Content-Element zwischen zwei Frames verschoben hat. Auch dieser Wert wird zum Viewport in Beziehung gesetzt.
Impact Region / Viewport = Impact Fraction
Der Layout Shift Score zeigt, dass Google die verschiedenen Displaygrößen in die Bewertung der User Experience einbezieht. Darüber hinaus wird der LSS einer Webseite mehrmals gemessen, die so gewonnenen Werte werden dann addiert. So entsteht der Cumulative Layout Shift.
Zwei Details sollten beim CLS beachtet werden: Durch die Verwendung von CSS-Bilder-Karussellen kann es zu wiederholten Verschiebungen im Layout kommen, was zur Folge hat, dass sich der Cumulative Layout Shift stark erhöhen kann.
Steve Kobes vom Google-Chrome-Team beschreibt in der Online-Konferenz #PerfMatters, wie Google dieses Problems Herr wird: „Unsere Lösung ist es, Veränderungen in der Transform Property zu ignorieren. Solange ein Karussell mit den Transform-Animationen implementiert ist, wird es den CLS nicht aufblähen.“ Transform verändert also nur die Position horizontal, nicht aber vertikal. Der User hat dadurch keinen Nachteil.
Außerdem soll Interaktion via Input – also beispielsweise durch einen Klick, der durch Ausklappen weitere Informationen lädt – mit einem Zeitfenster von 0,5 Sekunden erlaubt werden. So werden Funktionen nicht bestraft, die dem User eindeutig als Veränderung im Layout bekannt, d. h. vom Website-Betreiber gewollt sind.
Auch für den CLS hat Google Richtwerte für die Messung entwickelt.
Schaut man sich die Empfehlungen genauer an, die Google in seinem Webentwickler-Forum gibt, merkt man schnell, dass bisherige SEO-Maßnahmen weiterhin Relevanz haben. Die neuen Metriken sollten also nicht dazu führen, dass gut optimierte Seiten plötzlich schlecht dastehen. Das Optimieren der Server-Antwortzeit, das schnelle Laden minimierter Ressourcen, das Optimieren des sichtbaren Bereichs und die Bildoptimierung sind auch weiterhin wichtige Schritte hin zu einer guten Website.
Mit der neuen Lighthouse-Version 6.0, in die die neuen Metriken integriert sind, fallen Messungen und Werte aber sehr wohl anders aus als mit Lighthouse 5.0. Erste Vergleiche haben gezeigt, dass der PageSpeed-Score mit den neuen Web Vitals teils deutlich schlechter ist.
Die neuen Werte sollen vielmehr für Website-Betreiber, Entwickler und SEOs Schwachstellen spezifischer nachvollziehbar machen und eine verlässlichere Bewertung und Vergleichbarkeit zwischen Wettbewerberseiten ermöglichen. Wie geht man nun praktisch an die Bewertung des Status quo und die Optimierung der Seite heran?
Zur Messung der drei Metriken stehen ähnliche Tools und APIs zur Verfügung. Im Zentrum steht dabei die neue Lighthouse-Version 6.0 (aktuell noch im Betastadium). Mit ihr kann in Chrome gemessen werden, wie sich LCP und CLS verhalten (Abbildung 8). Der FID-Wert fehlt, da Lighthouse nur eine Testumgebung simuliert, es aber keinen richtigen Input vom User gibt. An dieser Stelle kann der Wert Total Blocking Time als Laboratory-Wert (Lab-Wert) genutzt werden.
Eine Alternative zu Lighthouse ist webpagetest.org, um die Werte abzufragen. Dort können Werte per JSON automatisiert für mehrere Seiten angefragt werden.
Neben dem Laboratory-Wert durch Lighthouse und webpagetest.org bietet der Chrome User Experience Report auch eine Übersicht über alle Werte. Der Chrome User Experience Report (CrUX) sammelt anonymisierte Userdaten für jede der Metriken. Diese Daten liegen auch den Werten der Tools PageSpeed Insights und denen der Search Console zugrunde.
Zudem finden sich die neuen Metriken auch in der Google Search Console wieder, wenngleich der Report dort weniger ausführlich ist. Man sollte ihn eher als erste Orientierung sehen und daraus gegebenenfalls eingehendere Analysen und Messungen ableiten.
Bei aufwendigeren Abfragen für mehrere Seiten können Skripte oder APIs hilfreich sein, die in Googles Web-Dev-Forum für die drei Metriken bereitgestellt werden. Zuletzt können die Werte auch über eine Chrome Extension erfragt werden: github.com/GoogleChrome/web-vitals-extension.
Während die Messungen dazu dienen, den Status quo einer Seite einzuschätzen, erfolgt die Identifikation problematischer Content-Elemente und Rendering-Prozesse mit anderen Hilfsmitteln. Schließlich muss mitunter für jede Seite eine spezifische Analyse erfolgen, um die Ursachen zu identifizieren.
Will man wissen, wie es auf der eigenen Website aussieht, kann man sich die Werte CLS und LCP mit den Chrome-Developer-Tools anschauen. CLS kann hierbei über „More Tools“, „Rendering“, „Layout Shift Box“ sichtbar gemacht werden. Sobald die Box angehakt ist, werden Veränderungen im Layout farbig markiert und die Bewegung wird nachvollziehbar.
Für den LCP muss in den Developer-Tools die Performance der Seite einmal aufgezeichnet werden. Sodann werden verschiedene Metriken sichtbar. Hier können durch Hovern oder Klicken mehr Informationen aufgerufen werden (Abbildung 11).
Will man nun die Schwachstellen optimieren, bieten sich für die verschiedenen Werte unterschiedliche Maßnahmen an (hier nur grobe Beschreibung):
Google selbst gibt dazu in seinem Web-Developer-Forum detaillierte Informationen:
1.web.dev/optimize-cls/
2. web.dev/optimize-lcp/
3. web.dev/optimize-fid/
Merken sollte man sich also, dass der Cumulative Layout Shift nur das reine Zeichnen einer Seite und die Verschiebungen auf ihr betrachtet. Wie lange es dann dauert, bis das wichtigste Content-Element geladen ist, wird im Largest Contentful Paint ausgedrückt. Der First Input Delay zielt hingegen darauf ab, die Interaktion des Users mit der Seite zu verbessern, ist also kein „passiver“, sondern ein „aktiver“ Wert. Er steht dem CLS daher näher als dem LCP.
Jeder Seitenbetreiber sollte sich die Core Web Vitals im Detail anschauen und für sich daraus Schlüsse ziehen. Wenn eine Domain viele URLs hat, die bei einer der drei Metriken im negativen Bereich liegen, besteht Handlungsbedarf. Spätestens 2021 wird der neue Ranking-Faktor schlechte Performance mit entsprechenden Sichtbarkeitsverlusten quittieren.
Wie die Sichtbarkeitsverluste oder -gewinne aussehen werden und ob die SERPs durch das Page-Experience-Update tatsächlich durcheinandergewirbelt werden, lässt sich aktuell noch schwer abschätzen. Hier dürften die spezifischen Werte der Domain und das Wettbewerberumfeld entscheidend sein. Positiv ist, dass Entwickler und SEOs mit den neuen Metriken genauer einschätzen können, wo im Einzelnen Handlungsbedarf besteht.