Die Core Web Vitals - Das bedeuten die neuen Kennzahlen wirklich

Inhalt

1. Neue Kennzahlen für einen user centric Approach
2. LCP - Largest Contentful Paint
3. FID – First Input Delay
4. CLS – Cumulative Layout Shift
5. Feld und Lab Daten - Der kleine, aber feine Unterschied
6. Analysieren Sie die Core Web Vitals für Ihre Seite
7. CWV Optimierung – The Next Level

1. Neue Kennzahlen für einen User-Centric Approach

Bevor wir erläutern, was hinter jeder KPI steckt, möchten wir einmal ausholen und erklären, warum es überhaupt neuer Kennzahlen bedarf. Bereits 2018 hat Google bekanntgegeben, dass die mobile Ladezeit ein Rankingfaktor für Search und Ads ist. Bislang existierte eine Reihe von Metriken für die Ladezeit, die Google in seinen Tools ausweist oder die über andere Tools ausgelesen werden können. Hier nur einmal ein Auszug:

• Time to First Byte (TTFB) oder Server Response Time
• First Paint
• First Contentful Paint (FCP)
• First Meaningful Paint (FMP)
• DOM Content Load
• Time to Interactive (TTI)
• Speed Index

Bis zu diesem Zeitpunkt war es schlichtweg nicht klar, auf welche der Kennzahlen man optimieren sollte, um auch in den organischen Suchergebnissen davon zu profitieren.

Zudem kann keine dieser Kennzahlen die Experience bemessen, die ein User tatsächlich auf der Seite hat. Die Zeit bis zur Interaktivität sagt beispielsweise lediglich aus, wie lange die Seite lädt, bis eine erstmalige Interaktion möglich ist. Sie zeigt aber nicht, was bis dahin passiert und ob der Nutzer bereits einen negativen Eindruck gewonnen hat. Mit den neuen Kennzahlen soll sich dies ändern. Seitenbetreiber können nun anhand von drei Metriken messen, welche Erfahrung der User mit der Seite hat.

2. LCP - Largest Contentful Paint

Diese Kennzahl wird im Netz gerne als gefühlte Ladezeit beschrieben oder als der Zeitpunkt, an dem der Hauptinhalt der Seite geladen ist. Diese Beschreibung ist nicht nur falsch, sondern auch sehr irreführend, wenn man an die Metriken TTI oder den Speed Index denkt. Diese wurden bisher als Metriken für die gefühlte Ladezeit herangezogen. Aus diesem Grund möchten wir einmal diese Kennzahlen klar voneinander trennen.

• Der Largest Contentful Paint ist der Zeitpunkt, an dem das größte sichtbare Content-Element der Seite geladen ist. Im Idealfall liegt der Wert bei maximal 2.5 Sekunden.

Dies kann ein Textblock oder auch ein Bühnenbild sein. Wichtig hierbei ist, dass es um das größte sichtbare Element auf der Seite geht, also Above-the-Fold. Nun mag man vielleicht denken, dass man diesen Zeitpunkt mit einer gefühlten Ladezeit gleichstellen könnte. Dem ist jedoch nicht so. Wird z.B. das größte Content-Element als erstes geladen während noch kein weiteres Element sichtbar ist, ist der LCP sehr gering. Die gefühlte Ladezeit wird nicht zwingend beeinflusst. Denn der Nutzer kann an dieser Stelle immer noch das Gefühl haben, die Seite sei nicht fertig geladen.

Auch die Aussage, dass mit dem LCP die Hauptinhalte einer Website geladen sind, müssen wir wiedersprechen. Denn wenn ein Teaserbild das größte Content-Element darstellt, ist dies nicht mit dem Hauptinhalt gleichzusetzen, welcher ggf. noch aus Header, Navigation und Headline besteht. Nun stellt sich die Frage, wie sich die gefühlte Ladezeit bemessen lässt. Wie schon erwähnt, stellen hier die Metriken TTI und der Speed Index die geeigneten Messwerte da. Die TTI besagt, ab wann ein User mit der Seite interagieren kann, der Speed Index hingegen nur, wann die wichtigsten Elemente geladen sind.

3. FID – First Input Delay

Auch über diese Kennzahl lassen sich einige Erklärungen im Netz finden. Viele Experten verwechseln die Metrik mit der oben genannten TTI und beschreiben sie als „Dauer bis der Nutzer mit der Seite interagieren kann“. Eine weniger falsche, dennoch irreführende Beschreibung ist „FID gibt an, wie schnell ein User mit der Seite interagieren kann“. Beide Beschreibungen würden vermuten lassen, dass es sich im eine Timing-Metrik handelt, dies ist jedoch nicht korrekt.

• Der First Input Delay ist die Zeit zwischen einer User Interaktion (z.B. Klick auf einen Button) und der Reaktion des Browsers auf diese, welche nicht höher als 100ms sein sollte.

Diese Metrik gibt also keinen Aufschluss darüber, wie schnell eine Seite lädt. Es handelt sich lediglich um die Reaktionszeit der Seite, wird auf Deutsch daher auch Eingabeverzögerung genannt. Diese Kennzahl ist nur mit einer Nutzerinteraktion messbar. Es ist demnach eine spezielle Datenquelle notwendig, welche im weiteren Verlauf noch erklärt wird. Oder springen Sie direkt zum Abschnitt 5. Feld und Lab Daten.

4. CLS – Cumulative Layout Shift

Die kumulative Layoutverschiebung ist die besondere Metrik unter den neuen Kennzahlen. Denn der CLS Wert ist keine Zeitangabe, sondern ein Score Wert. Die Erläuterungen im Netz sind in der Regel korrekt, jedoch meistens nicht tief genug erklärt, um die Kennzahl ausreichend zu verstehen.

• Die kumulative Layoutverschiebung bestimmt, wie häufig User unerwartete Verschiebungen im Layout einer Seite wahrnehmen. Der CLS Score sollte nicht höher als 0.1 sein.

Der Score der Layoutverschiebung berechnet sich durch die impact fraction, der sichtbare Bereich, welcher von der Verschiebung betroffen ist, multipliziert mit der distance franction, also die Distanz, die ein Element zurücklegt. 

Dies lässt sich anhand eins Beispiels am besten verstehen. Nehmen wir ein Content-Element, welches 50 % des Viewports einnimmt und sich während des Ladeprozesses um 25 % nach unten verschiebt. Hier wäre der Raum, den die Verschiebung des Viewportes einnimmt, also 75 %. Die impact fraction in diesem Szenario läge bei 0.75. Da sich das Element um 25 % verschiebt wäre die distance fraction 0.25. Bei einer Berechnung des CLS Wertes impact fraction* distance fraction würde dies eine Rechnung von 0.75*0.25 = 0.1875 bedeuten – die Layoutverschiebung wäre also über dem Richtwert.

Wichtig: Nicht alle Layoutverschiebungen sind schlecht! Beim CLS Score geht es lediglich um die „unerwarteten“ Layoutverschiebungen. Veränderungen im Layout, welche nach einer Interaktion (Klick auf ein Element) folgen, werden hier nicht berücksichtigt.

Bei den Core Web Vitals handelt es sich also nicht um Timing-Metriken. Es sind keine Kennzahlen, um die Ladezeit der Seite zu messen. Hierfür sollte der bereits erwähnte Speed Index (Hauptinhalte geladen) oder die TTI (Zeit bis zur Interaktivität) herangezogen werden.

5. Feld und Lab Daten - Der kleine, aber feine Unterschied

Nun, da wir einen Blick auf die neuen Kennzahlen geworfen haben, stellt sich die Frage, wie sich diese bemessen lassen. Bevor wir auf die einzelnen Datenquellen eingehen, wollen wir jedoch den Unterschied zwischen Feld- und Labdaten aufzeigen.

Labdaten werden innerhalb einer kontrollierten Umgebung mit vordefinierten Geräte- und Netzwerkeinstellungen gesammelt.

Felddaten hingegen werden aus realen Seitenaufrufen von realen Nutzern gesammelt.

Die daraus resultierenden Unterschiede sind wie folgt:

Wie bereits erwähnt, ist für den FID eine Nutzerinteraktion notwendig. Diese Kennzahl kann daher nur mit Hilfe von Felddaten generiert werden.

Außerdem können unterschiedliche Datenerhebungen zu sehr unterschiedlichen Werten der web vitals führen. Dies hat den einfachen Grund, dass Labdaten sich die Seite nur bis zu dem Zeitpunkt ansehen, bis sie vollständig geladen ist. Felddaten betrachten hingegen die gesamte Visit Time eines echten Users. Zum Verständnis: Kommt es nicht nur während der Ladezeit einer Seite zu einer Layoutverschiebung, sondern auch während des Scrollings, ist der CLS-Wert aus Felddaten höher als der der Labdaten, welche nur den Ladeprozess betrachteten. Ebenso wird der FID-Wert, der Wert der Eingabeverzögerung, für die Felddaten 0 sein, wenn Nutzer keine Interaktion tätigen.

Felddaten stehen jedoch nicht für alle Domains bzw. Seiten zur Verfügung. Google gibt einen relativen Wert der Kennzahlen über alle Besuche hinweg aus. Verfügt eine Website nicht über ausreichend Website Traffic, sind diese Werte nicht aussagekräftig und werden auch nicht auf URL-Ebene ausgegeben.

6. Analysieren Sie die Core Web Vitals für Ihre Seite

Wenn Sie ganz einfach herausfinden wollen, ob Sie im Bereich der Core Web Vitals Optimierungen an Ihrer Website tätigen müssen, bedarf es im Idealfall der Google Search Console (GSC). Dieses Tool präsentiert Websitebetreibern die Daten, die Google über diese Website durch die organische Suche sammelt. Seit dem Launch der neuen KPIs, weist Google auch diese in der Console unter dem Bericht „Core Web Vitals“ aus. Hier ist sehr schnell zu erkennen, ob Optimierungspotenziale bestehen. (Vgl. Bilder in der Bildergalerie)

Durch den Export der Beispiel-URLs können mithilfe dieser Daten Rückschlüsse auf Seitentypen gezogen werden, welche optimiert werden müssen. Die Daten in diesem Bericht werden aus dem Chrome UX Report gezogen. Es handelt sich hierbei also, sofern vorhanden, um Felddaten.

Haben Sie die Zugänge für die Google Search Console nicht zur Hand, ist ein Blick in die PageSpeed Insights (PSI) ebenso hilfreich. Hier sehen Sie nach Eingabe einer URL auch Felddaten, wenn diese für Ihre Domain vorhanden sind. Sie können sogar Daten der „Origin Summary“, also die Werte über die gesamte Domain hinweg, einblenden. Der dort erwähnte „Core Web Vitals-Test“ hat eine Seite oder Domain dann bestanden, wenn sich der Wert einer Kennzahl in 75 % der Fälle (Visits) im grünen Bereich befindet. Sind keine Felddaten vorhanden weist das Tool hier Labdaten aus.

7. CWV Optimierung – The Next Level

Natürlich kann eine manuelle Prüfung besonders bei großen Websites sehr mühselig und wenig praktikabel sein. Über die Schnittstelle beider Tools, Chrome UX Report (CrUX) sowie auch PageSpeed Insights (PSI), können Daten automatisiert gezogen und analysiert werden – auch auf URL-Ebene. Bei EPROFESSIONAL haben wir uns dies mit der Hilfe unserer Google Ansprechpartner zum Vorteil gemacht. In den letzten Monaten haben wir nicht nur einen Speed Audit entwickelt, um Potentiale zu identifizieren. Wir haben auch ein Speed Monitoring entworfen, um die Entwicklung der KPIs zu betrachten.

Der Speed Audit analysiert jedoch weitaus mehr als einzelne Seitenbereiche. Nachdem diese mit den PSI und CrUX Daten definiert wurden, geht es in eine tiefere Analyse, um Handlungsempfehlungen zu bilden. Dabei lassen sich für jede Kennzahl unterschiedliche Potenzialfelder identifizieren und daraus Handlungsempfehlungen ableiten. Für die Optimierung des CLS-Wertes sind daher andere Anpassungen nötig wie beispielsweiße für den LCP Wert. Im Folgenden ein paar Beispiele, welche Bereiche Einfluss auf die einzelnen KPIs haben:

LCP optimieren

• Blockierendes JavaScript und CSS
• Komprimierung von Ressourcen
• Serverantwortzeiten

FID optimieren

• Ausführungszeit von JavaScript
• Asynchrone JavaScript Tasks

CLS optimieren

• Dimensionsangaben für Bilder
• Webfonts
• Dynamische Inhalte

Fazit

Zusammengefasst lässt sich sicher sagen, dass die neuen Core Web Vitals ein komplexes Thema ist, welches häufig aufgrund geringer Recherche fehlinterpretiert wird. Natürlich hätte auch dieser Artikel noch tiefer in die einzelnen Metriken einsteigen können. Dennoch hoffen wir, dass wir ein Grundverständnis für die einzelnen KPIs schaffen konnten. Wir hoffen auch, dass durch die Informationen klar geworden ist, dass es sich bei den Core Web Vitals nicht um klassische KPIs aus der Ladezeit-Optimierung, sondern um nutzerzentrierte Kennzahlen handelt. Für alles weitere hat Google mit web.dev eine ganze Reihe an tiefgreifenden Fachinformationen zusammengestellt, die dabei helfen, die Thematik zu verstehen und technische Aspekte besser greifen zu können.

Autorin: Esther Kaltenbach

Sie benötigen Unterstützung bei der Interpretation der Core Web Vitals oder generell im Bereich SEO für Ihre Brand? Dann kontaktieren Sie uns.

Imke Tietjen steht Ihnen für Ihre Anliegen zur Verfügung: Jetzt E-Mail schreiben