Google Web Vitals: Performance KPIs für UX und SEO

Es ist nichts Neues, dass Google großen Wert auf die Performance und die damit verbundene Nutzererfahrung (User Experience) eines Internetauftritts legt. Bisher standen für die Performance-Messung mit Pagespeed Insights, Google Lighthouse sowie dem Geschwindigkeitsreport der Google Search Console unterschiedliche Tools zur Verfügung. Mit den Web Vitals präsentiert Google nun ein transparentes Bewertungssystem, dass exaktere Analysemöglichkeiten durch genau definierte KPIs zur Website-Performance sowie Nutzererfahrung gewährleistet und in einem Gesamtbericht zusammenfasst.

Das mit den Core Web Vitals verbundene Algorithmus Update wird ab Mitte Juni 2021 von Google schrittweise implementiert und die Gewichtung von klassischen Rankingkriterien um folgende ergänzen:

• Ladeerlebnis
• Interaktivität
• Visuelle Seitenstabilität

Zeitlich passend zum Update stellt Google über die hauseigene Search Console ein neues Modul vor, das einen Überblick über die Nutzerfreundlichkeit von Seiten geben soll:

• Nutzerfreundlichkeit von mobilen Webseiten

Google selbst umschreibt die Neuerung mit folgenden Worten:

“Core Web Vitals are a set of real-world, user-centered metrics that quantify key aspects of the user experience. They measure dimensions of web usability such as load time, interactivity, and the stability of content as it loads (so you don’t accidentally tap that button when it shifts under your finger – how annoying!)” 

Wie genau die Web Vitals funktionieren erklären wir im Beitrag. Passend hierzu beschäftigen wir uns mit Optimierungsansätzen bezüglich Layout Shifts bei Ads und Anzeigen sowie mit einem Exkurs zum Thema Content-Preload.

Was sind Web Vitals?

Web Vitals sind einzelne, von Google definierte, Messwerte die von der Suchmaschine als strategisch wichtige Qualitätssignale ausgewertet werden. In erster Linie gibt Google hier klare Bewertungsfaktoren vor, die sicherstellen, dass eine Seite dem Nutzer ein möglichst gutes und passendes Suchergebnis liefert. Bei einer Optimierung der Web Vitals sollte man sich fragen: Wie interagiert der Nutzer mit unserer Website und wie funktionsfähig und somit zielführend ist unser Internetauftritt letztendlich als Suchergebnis?

Was ist das Ziel von Web Vitals?

Die Möglichkeit einen einheitlichen Gesamt-Bericht via Web Vitals zu ziehen, bietet für den Website-betreiber mehr Transparenz für konkrete Optimierungen und damit das Potenzial bessere Nutzererfahrungen mit dem eigenen Internetauftritt zu erreichen. So will Google sicherstellen, dass der User ein möglichst passendes Suchergebnis zu seiner Anfrage geliefert bekommt.

Welche Web Vitals gibt es?

Googles Web Vitals lassen sich in zwei Kernbereiche aufteilen: Primary Web Vitals (Core Web Vitals) und Secondary Web Vitals. Aber was heißt das eigentlich genau?

Primary Web Vitals

Die Primary Web Vitals (Core Web Vitals) kümmern sich um die Messbarkeit und Skalierung der Nutzererfahrung. Folgende Punkte werden hierbei betrachtet: Ladevorgang durch den LCP Wert, visuelle Stabilität über den FID sowie das Interaktionsverhalten über die CLS.

LCP (Largest Contentful Paint)

Umfasst die Ladeperformance und beschreibt den Punkt im Ladevorgang, an dem die Kernelemente einer URL vollständig geladen und für den Nutzer verfügbar sind. Es wird empfohlen einen LCP Wert von unter 2,5 Sekunden zu erreichen. Relevante Seitenelemente sollten also nach 2,5 Sekunden vollständig geladen sein, während Subelemente nachgeladen werden können. Eine nützliche Funktion um Ressourcen während des Ladevorgangs zu priorisieren ist der sogenannte Content Preload, auf welchen wir in unserem Folgeartikel SEO – Ladezeitoptimierung: Content Preload näher eingehen.

 

 

Welche Elemente nehmen auf LCP Einfluss?

• <img> Elemente
• <image> Elemente innerhalb eines <svg> Elements
• <video> Elemente
• Ein Element mit einem Hintergrundbild, das über die url() function geladen wird, statt per CSS
• Block-Elemente, die Textelemente enthalten.

Tools für die Messbarkeit des LCPs

• Chrome User Experience Report
• PageSpeed Insights
• Search Console (Core Web Vitals Report)
• Chrome DevTools
• Lighthouse
• WebPageTest

Vorgehen, um LCP Messwerte zu optimieren

Primäre Faktoren:

• Server Response Times reduzieren
• Render-blocking JavaScript and CSS
• Resource Load Times
• Client-side Rendering

Weiterführende Faktoren:

• • Verwendung von Instant Loading
  • Optimierung des Critical Rendering Path
  • Optimierung von CSS

• Optimierung von Bildern
• Optimierung von Web Fonts
• Optimierung von JavaScript

FID (First Input Delay)

Dieser Wert umfasst die vom Nutzer ausgehende Interaktion mit der Zielseite und wie schnell diese mit ihrem technischen Hintergrund darauf reagieren kann. Die Zeitspanne des First Input Delays reicht von der getätigten Interaktion bis hin zur ersten serverseitigen Reaktion darauf. Ein Wert unter 100 Millisekunden stellt sicher, dass der Nutzer die ihm gebotenen Inhalte schnell und einfach auffassen kann und er seine Suchintention in den Inhalten der Seite erfüllt sieht.

 

 

Was zählt als FID und weshalb wird nur der „first input“ herangezogen?

Der FID ist ein Messwert, der die Zugänglichkeit einer URL während des Ladeprozesses abbildet. Der Fokus liegt auf der Zeitspanne zwischen Ladebeginn und der ersten Nutzerinteraktion. Folgende Interaktionen werden gezählt:

• Klicks
• Tippen
• Tastendruck

Interaktionen wie Zoomen oder Scrollen sind ebenfalls wichtige KPIs für Web Vitals, werden jedoch für den FID nicht als Messwert genutzt. Betrachtet man das Google bekannte RAIL Modell, ordnet sich der Wert FID direkt am Anfang unter dem Punkt „R“ (Responsiveness) ein.

Wieso wird der Fokus auf den „first input“ gelegt?

• Die erste Interaktion spiegelt auch den ersten Eindruck des Nutzers der Zugänglichkeit der Seiteninhalte wider. Google legt einen großen Wert auf den Ersteindruck, um daran Qualität und Verlässlichkeit zu messen.
• Gibt es direkt zu Anfang große Ladeprobleme oder Anzeigeprobleme, zeigen sich diese im FID. Der erste Nutzereindruck sollte so perfekt wie möglich gestaltet werden, um nach dem Seiteneinstieg alle folgenden Interaktionen sowie die Nutzeraktivität zu steigern.
• Google unterteilt in zwei Bewertungen: „First input delays“, die stattfinden sollten bevor alle Ressourcen der Seite geladen sind, und darauffolgende „input delays“, die erst nach dem vollständigen Ladevorgang stattfinden.

Tools für die Messbarkeit des FIDs

• Chrome User Experience Report
• PageSpeed Insights
• Search Console (Core Web Vitals report)
• Firebase Performance Monitoring (Beta)

Vorgehen, um den FID zu optimieren

• • Optimierung der TBT
  • Eliminierung von Render-Blocking Resources
  • Bilder in der passenden Größe hinterlegen
  • CSS minimieren
  • JavaScript minimieren
  • Nicht verwendetes CSS entfernen
  • Effizienter Einsatz von Bilder-Encoding
  • Moderne Formate von Bildern bereitstellen (PNG 2000)
  • Textkomprimierung aktivieren
  • Server Response Times (TTFB) reduzieren
  • Multiple Page Redirects entfernen
  • Key Requests vorladen
  • Aktuelle Video Formate verwenden
  • Third-party Code vermindern
  • JavaScript Execution Time vermindern

• Main Thread Work vermindern
• Anzahl der Requests geringhalten und wenige Daten übertragen

 

CLS (Cumulative Layout Shift)

Umfasst die „visuelle Stabilität“ des Designs. Je statischer einzelne Seitenelemente während des Ladevorgangs sind, desto weniger Verschiebung wird von Google als negativ bewertet. Als „Layout Shift“ bezeichnet man die Verschiebung einzelner Elemente während des Ladeprozesses.

Aufgrund unerwarteter Verschiebungen von Seitenelementen, sind zum Beispiel Texte schwerer zu lesen und Buttons schwerer zu klicken. Wenn ein Button sich genau in dem Moment verschiebt, in dem der User versucht diesen anzuklicken, kann unter Umständen versehentlich ein anderes, falsches Feld angeklickt werden.

 

CLS: Layout Shifts im Detail

Der CLS Wert folgt der Leitfrage:

„Are the interactions smooth and natural, free of lag and jank?“

Um den CLS zu berechnen, wird die folgende Formel von Google zur Verfügung gestellt:

layout shift score = impact fraction * distance fraction

Impact Fraction

Die Impact Fraction misst, wie sehr sich einzelne Elemente zwischen zwei Frames verschieben. Gemessen wird die gesamte sichtbare Fläche, die sich verändert. Hierzu wird die Sichtbarkeit eines Elements vor und nach einem Layout Shift in prozentualer Relation zu der für den Nutzer gesamten sichtbaren Fläche gesetzt. Die Verschiebung ergibt somit einen prozentualen Wert, der abschließend von 100 abgezogen wird. Wandert ein Element um 25% innerhalb des sichtbaren Bereiches nach unten, ergibt sich somit ein Wert von 0,75.

Distance Fraction

Um die Distance Fraction zu berechnen, muss ermittelt werden in welcher Dimension (horizontal oder vertikal) sich das Elemente am meisten verschoben hat und welche Dimension den größeren sichtbaren Anteil (auf dem Bildschirm) ausmacht. Wandert ein Element auf einem Smart Device um 25% im sichtbaren Teil nach unten, ergibt sich ein Wert von 0,75.

0.1875 = 0,75 * 0,25

Anwendungsbeispiel:

Nutzerausgelöste Layout Shifts

Nicht alle Layout Shifts werden negativ gewertet. Ist für den Nutzer deutlich ersichtlich, dass nach einer Interaktion eine visuelle Veränderung der Seite stattfinden wird (z.B. durch Klicken eines Links, Öffnen einer Tab-Box oder Nutzen einer Sprungmarke), werden diese Layout Shifts von Google nicht als störend bewertet. Bei Layoutverschiebungen, die innerhalb von 500 Millisekunden nach Benutzereingabe auftreten, wird die Flag „hadRecentInput“ gesetzt, sodass diese von einer Negativbewertung ausgeschlossen wird.

Tipps für Animationen und ähnliche Elemente:

Mit der CSS „transform“ property können Sie Elemente animieren, ohne Layoutverschiebungen auszulösen:

• Statt die Height- und Width Properties zu ändern, sollte transform: scale() genutzt werden.
• Um Elemente zu bewegen sollte auf die Verwendung von top, right, bottom, left properties verzichtet werden. Stattdessen empfehlen wir die Verwendung des transform: translate() Befehls.

Tools für die Messbarkeit des CLS

• Chrome User Experience Report
• PageSpeed Insights
• Search Console (Core Web Vitals report)
• Chrome DevTools
• Lighthouse
• WebPageTest

Vorgehen, um CLS niedrig zu halten

• Bei Bildern und Videos sollten voreingestellte Größenattribute verwendet oder die CSS-Funktion der Aspect Radio Boxes aktiviert werden, um durch Größenänderung benötigte Plätze zu reservieren.
• Statische Inhalte sollten niemals von dynamischen überblendet werden, außer als Reaktion auf eine Benutzerinteraktion.
• Animationen sollten transformiert werden, statt ihnen im Quellcode Eigenschaften zu hinterlegen, die das Layout abändern.

Secondary Web Vitals

Die Secondary Web Vitals sind den Primary als untergeordnet zu betrachten, da sie als einzelne messbare Bestandteilte der Primary Web Vitals gelten und diesen somit zweitrangig sind. Sie geben Aufschluss darüber, wie stabil das technische Grundgerüst einer Zielseite für den Nutzer ist. Unter allen SEO-treibenden sind die Secondary Web Vitals zwar schon lange nichts Neues mehr, zur Vollständigkeit der Web Vitals als Ganzes dürfen aber auch sie nicht fehlen:

TTFB (Time To First Byte)

Zeigt an, wieviel Zeit vergeht, bis der verwendete Server eine Antwort wiedergibt.

FCP (First Contentful Paint)

Steht für den Punkt innerhalb des Ladevorgangs, an dem alle Elemente im sichtbaren Bereich des Bildschirms gerendert wurden.

TBT (Total Blocking Time)

Umschreibt die Zeit zwischen FCP und TTI, währenddessen der Main Thread blockiert und die Reaktionsfähigkeit der Zielseite eingeschränkt ist. So muss der Ladevorgang des aktiven Tasks erst abgeschlossen werden bevor der Nutzer mit der Seite interagieren kann. Je höher diese Zeitspanne desto schlechter ist sie für die Nutzererfahrung.

TTI (Time To Interactive)

Misst die Zeit vom Beginn des Ladens der Seite bis zum Ladeabschluss der wichtigsten Unterressourcen. Es muss der Punkt ermittelt werden, an dem die Zielseite in der Lage ist, schnell und zuverlässig auf Benutzereingaben zu reagieren.

Web Vitals weitergedacht

Für alle, die gerne ein wenig über den Tellerrand schauen, haben wir selbst KPIs definiert, die indirekt Aussagen über das Zusammenspiel zwischen der Zielseite, dem Nutzer sowie dem Suchergebnis geben könnten.

• Time On Site
  Wie lange ist der Nutzer auf unserer Zielseite? Bieten die Inhalte genug Informationen, um die Suchintention zu befriedigen?

• Further Navigation Action
  Ist unsere Zielseite ausreichend, um die Suchintention abzudecken oder muss der Nutzer auf weitere URLs weiternavigieren. Wird der Nutzer zudem gut durch unsere Seite geführt und sind die navigationalen Elemente gut verständlich?

• Actions On Site
  Interagiert der Nutzer mit den Möglichkeiten, die wir ihm auf unserer Zielseite zur Verfügung stellen? Gibt es redundante Elemente bzw. solche, die so viel genutzt werden, dass sie präsenter platziert oder erweitert werden sollten?

• Leap Rate
  Wie hoch ist die Absprungrate unserer Zielseite und was könnten Gründe für diesen Wert sein?

• Search Intent Satisfaction
  Wird die Intention bzw. Fragestellung, die hinter dem vom Nutzer eingetippten Keyword steht, mit unserer Zielseite fachgerecht beantwortet oder müssen wir nachliefern und verbessern?

• Searched Keyword vs. Content On Site
  Landet der Nutzer auf einer semantisch zum Keyword passenden Zielseite?

Signale für die Nutzerfreundlichkeit einer Seite

Mit der Auswertung für die Nutzerfreundlichkeit einer Domain in der Google Search Console schafft Google ein übersichtliches Dashboard um nachvollziehen zu können wie die Suchmaschine die hinterlegte Property auf Nutzerfreundlichkeit bewertet.

 

Signale für die Nutzerfreundlichkeit einer Seite
Core Web Vitals	Die Seite bietet im Hinblick auf Ladezeiten, Interaktivität und visuelle Stabilität eine gute Nutzerfreundlichkeit: Largest Contentful Paint (LCP): Hiermit wird die Ladeleistung gemessen. Für eine gute Nutzerfreundlichkeit sollten Websites einen LCP innerhalb der ersten 2,5 Sekunden des Ladevorgangs anstreben. First Input Delay (FID): Hiermit wird die Interaktivität gemessen. Für eine gute Nutzerfreundlichkeit sollten Websites einen FID von weniger als 100 Millisekunden anstreben. Cumulative Layout Shift (CLS): Hiermit wird die visuelle Stabilität gemessen. Für eine gute Nutzerfreundlichkeit sollten Websites einen CLS-Wert von weniger als 0,1 anstreben.
Für Mobilgeräte optimiert	Die Seite ist für Mobilgeräte optimiert. Der Test auf Optimierung für Mobilgeräte analysiert, ob eine Seite auch auf Mobilgeräten optimal funktioniert.
Safe Browsing	Die Seite enthält keine schädlichen (z. B. Malware) oder betrügerischen Inhalte (z. B. Social Engineering). Anhand des Berichts „Sicherheitsprobleme“ ist prüfbar, ob eine Website Probleme mit Safe Browsing hat.
HTTPS	Die Seite wird über HTTPS zur Verfügung gestellt. Ob eine Verbindung zu einer Domain sicher ist, kann hier geprüft werden. Wenn die Seite nicht über HTTPS geladen wird, erfährt man hier, wie eine Website mit HTTPS sicherer gestalten werden kann.
Keine störenden Interstitials	Der Inhalt der Seite ist für den Nutzer leicht zugänglich. Weitere Informationen zu Interstitials, die den Zugriff auf Inhalte erschweren.

Gibt es Änderungen innerhalb der Web Vitals KPIs?

Wer mehr über Googles Web Vitals erfahren und immer up to date bleiben möchte, der verfolgt diesem Blog-Artikel oder prüft die von Google dokumentierten Changelogs.

 

Über den Autor

Dennis Kurz

Senior Executive SEO
Köln

Dennis Kurz ist als Senior Executive im Fachbereich Suchmaschinenoptimierung (SEO) der Resolution Media am Standort Köln tätig und schreibt über Online Marketing sowie digitales Quer- und Neudenken.