Core Web Vitals erklärt und zu Google Analytics hinzufügen

Google kündigte vor kurzem eine größeres Update für 2021 an, wie die Website-Performance das Suchranking beeinflussen wird. In Zukunft wird es einen zusätzlichen Schwerpunkt auf einer Reihe von Metriken geben, den so genannten Core Web Vitals. Diese  konzentrieren sich darauf, wie Ihre Besucher die Performance Ihrer Website wahrnehmen. Diese Kennwerte gehen ein größeres Problem an, wie bis dato die Website-Performance gemessen wurde.

Ältere Metriken wie “Page Weight” beschreiben spezifische Netzwerk- oder Berechnungsressourcen, die möglicherweise belastet werden. Sie beschreiben aber nicht direkt das Ausmaß, welche Seitenerfahrung die Benutzer dadurch vielleicht haben. Folglich war es schwierig festzustellen, was eine “gute” Pageweigth ist, abgesehen von der Floskel „kleiner ist besser“.

In diesem Artikel zeige ich Ihnen, wie Sie die Core Webvitals in Google Analytics integrieren können. Wenn Sie nur nach den GTM-Tags und Triggern suchen, um dies zu erreichen, können Sie sie hier herunterladen.

Das Problem mit Google Analytics Metriken zur Seitengeschwindigkeit

Im Moment bleiben die Nutzer von Google Analytics bei der alten Methode zur Messung der Website-Performance stecken. Der Abschnitt “Seitentimings” von GA bietet viele einzelne Metriken wie “Server-Antwortzeit” und “Seiten-Downloadzeit”, die zusammengenommen immer noch nichts darüber aussagen, was der Nutzer beim Laden einer Seite erlebt hat. Die bei weitem schädlichste Metrik ist die “durchschnittliche Seitenladezeit”. Diese Metrik ist nicht nur schlecht konzipiert (z.B.: das Laden eines großen Bildes außerhalb des Ansichtsfensters erhöht die “Ladezeit”, würde aber die Erfahrung des Benutzers nicht beeinträchtigen), sondern die Verwendung eines Durchschnitts ist eine gefährliche Art und Weise, eine solche variable Metrik zu aggregieren. Außerdem werden diese Metriken standardmäßig von nur 1% der Benutzer gesammelt.

Was sind Core Web-Vitals?

Im Moment gibt es 3 Web Vitals, die Google für die wichtigsten gehalten hat.

Largest Contentful Paint (Größter Inhalt geladen)

LCP misst die “wahrgenommene Ladegeschwindigkeit”, indem die Zeit gemessen wird, die es dauert, bis das größte Element im Sichtfenster des Benutzers erscheint. Google empfiehlt, dass 75% Ihrer Seiten einen LCP-Wert unter 2,5 Sekunden erzeugen (segmentiert nach Mobil- und Desktop-Nutzern).

First Input Delay (Erste Eingabeverzögerung)

Der Wert FIP misst die ‘Lade Reaktionsfähigkeit’, indem sie die Zeit zwischen der ersten Interaktion des Benutzers und der Auflösung dieser Interaktion misst. Diese Metrik zielt auf große JavaScript-Dateien ab, die nicht überprüft wurden und den Hauptthread des Browsers blockieren, wodurch die Interaktivität mit der Seite verzögert wird. Als Nutzer kann man in dieser Zeitspanne die Seite noch nicht benutzen. Google empfiehlt hier, dass 75% Ihrer Seiten einen FIP-Wert unter 100 ms erzeugen (segmentiert nach Mobil- und Desktop-Nutzern).

Cumulative Layout Shift (Kumulative Layout-Verschiebung)

CLS misst die “visuelle Stabilität”. Es ist eine kombinierte Metrik aus zwei Punkten berechnet wird.

1. Wie weit verschieben sich HTML-Elemente während eines Ladevorgangs der Seite
2. Wie weit wurde die Gesamtfläche verschoben

Auf diese Weise sind kleine Elemente, die sich stark verschieben, genauso schlecht wie große Elemente, die sich ein wenig verschieben. Google empfiehlt, dass 75 % Ihrer Seiten eine CLS-Bewertung von unter .1 ergeben (segmentiert nach Mobil- und Desktop-Nutzern).

Die JavaScript-Bibliothek für Web Vitals

Das Senden dieser Metriken an Google Analytics mithilfe der JavaScript-Bibliothek von web-vitals ist ziemlich einfach. Beachten Sie, dass die Erfassung von Webvitals- Daten nur mit Chromium-basierten Browsern (größtenteils) wie hier beschrieben funktioniert.

Die web-vitals-Bibliothek enthält einige Funktionen wie getCLS und getFID, die auf die API des Browsers zugreifen, um die zur Berechnung der einzelnen Metriken erforderlichen Daten abzurufen. Der Vorteil dieses Ansatzes besteht darin, dass wir die Bibliothek jederzeit laden können, um unsere Leistungsergebnisse zu sammeln. Jeder gemessenen Metrik ist eine “id” zugeordnet, die die Instanz identifiziert, in der Daten auf einer einzelnen Seite im Laufe der Zeit gesammelt wurden. Sie können diese ID verwenden, um später Häufigkeitsverteilungen zu erstellen in welchem Erfahrungsbereich wieviel Nutzer sich bewegen.

Zwei der wichtigsten Webvitals, CLS und LCP, melden oft mehrere Werte während eines einzigen Seitenaufrufs. Dies ist sinnvoll, wenn man darüber nachdenkt. Das “größte” geladene Element kann sich im Laufe der Zeit ändern, und die “kumulative” Layoutverschiebung soll die Gesamtsumme aller Verschiebungen darstellen, die der Benutzer im Laufe der Zeit erfahren hat. Glücklicherweise bietet die Web-Vitals Bibliothek ein isFinal-Flag, das anzeigt, welche Metrik der Endwert ist, vermutlich weil der Benutzer auf einen Link geklickt oder die Registerkarte geschlossen hat. Aus diesem Grund nutzt unsere GTM-Implementierung das transport:beacon Google Analytics-Feld, um sicherzustellen, dass unsere Daten an GA gesendet werden können, ohne die Navigation des Benutzers weg von der Seite zu unterbrechen.

Update: Wie Phil Walton von Google betont jedoch folgendes isFinal birgt das Risiko, dass wir die CLS-Metrik komplett verlieren, da wir uns nicht zuverlässig auf die Ereignisse des Unload-Event-Handlers verlassen können. Siehe hier. Im Idealfall würden wir jedes CLS-Ereignis erfassen und dann über einzelne Nutzer + Seiten aggregieren, um die maximalen Wert von CLS pro Nutzer und Seitenaufruf zu ermitteln. Dies erfordert, dass Sie die Client-ID des Benutzers im GA verfolgen, die standardmäßig nicht über die Reporting-API verfügbar ist.

Senden von Web Vitals an Google Analytics mithilfe von Google Tag Manager

Ich habe hier einen GTM-Container-Export erstellt, der die Tags, Trigger und Variablen enthält, die erforderlich sind, um Web-Vitals-Daten als Ereignisdaten an GA zu senden. Google hat hier einen Beispielcode zur Verfügung gestellt, falls Sie diese Daten ohne Verwendung von GTM direkt an GA senden möchten.

Der Container selbst sollte ziemlich leicht verständlich sein. Das einzige Feld, das Sie bearbeiten müssen, ist die “GA Property ID”-Variable, die durch Ihre eigene GA Property ID ersetzt werden sollte.

Die Web-Vitals-Metriken werden als Google Analytics-Ereignisse mit den folgenden Feldern gesendet:

• Event Category: Web Vital
• Event Action: {{Vital Name}}
• Event Label: {{Vital ID}}
• Event Value: {{Vital Value}}

Der Code, der dafür verantwortlich ist folgt hier:

<script defer src="https://unpkg.com/web-vitals@0.2.2/dist/web-vitals.es5.umd.min.js"</script>
<script>
function sendVital(metric){
if(metric.isFinal)
{
//Convert CLS to integer
metric.value = Math.round(metric.name === 'CLS' ? metric.value * 1000 : metric.value);
dataLayer.push({"event":"Vital Reported",
"vital.name":metric.name,
"vital.value":metric.value,
"vital.id":metric.id});
}
}

webVitals.getCLS(sendVital,true);
webVitals.getFID(sendVital);
webVitals.getLCP(sendVital,true);
</script>

Zunächst laden wir die Web-Vitals Bibliothek aus einem CDN. Als Nächstes definieren wir eine Callback-Funktion, die Web-Vitals aufruft, sobald eine Metrik verfügbar ist. Innerhalb dieser Callback-Funktion prüfen wir, ob der Wert der Metrik ihr “endgültiger ” Wert ist. Außerdem multiplizieren wir den CLS-Score mit 1000, da GA-Ereigniswerte ganze Zahlen sein müssen. Schließlich rufen wir getCLS, getFIP und getLCP auf, um jede der drei Metriken anzufordern.

Ergebnisse

So sollten die Daten nachher aussehen, wenn alles richtig funktioniert.

Dennoch würde ich Ihnen nicht empfehlen, auf diese Weise über Ihre Ergebnisse zu berichten. Denn was wir suchen, ist nicht der “Durchschnittswert” für irgendeine dieser Messgrößen, sondern der Wert, unter dem 75% unserer Seiten liegen. Der Blick auf das 75. Perzentil ist eine viel aussagekräftigere Art der Interpretation der Ergebnisse, die gegenüber Ausreißern robust ist. Wir möchten unsere Daten auch nach Desktop- & Tablet- gegenüber mobilen Benutzern segmentieren, um sicherzustellen, dass unsere Ergebnisse geräteübergreifend stabil sind.

Visualisierung von Webvitals Daten in Data Studio

Um die Daten mit dem 75% Perzentil darzustellen, benötigen wir eine extra Berechnung, die wir besser nicht direkt in Google Datastudio durchführen sollten. Warum man besser nicht in Data Studio direkt berechnet, habe ich hier ausführlich dargelegt.

Hierfür gibt es zwei schnelle Wege. Entweder über Google Sheets mithilfe des Google Analytics Addons oder falls Sie über Google Analytics 360 verfügen sollten, auch über Bigquery Export. Für unseren kleinen Test habe ich einmalig mithilfe des Addons folgendermaßen die Daten aus meinem Blog exportiert:

Hierdurch werden bei der Erstellung der Reports 3 weitere Tabellenreiter erstellt mit den jeweiligen Daten. Auf diese referenziere ich und ziehe mit der entsprechenden PERCENTIL Formel die Daten pro Tag für die Metriken CLS, LCP und FID. Vorsicht: bei CLS müssen wir wieder durch 1000 teilen, da wir in unserem ursprünglichen Javascript bei der Erfassung x1000 gerechnet hatten.

Diesen aggregierte Tabellenreiter füge ich dann als Datenquelle in Data Studio hinzu und kann sie dann entsprechend darstellen lassen.

Bitte verzeihen Sie die geringe Datenmenge und deren Qualität. Dies habe ich schnell auf einer Testseite installiert, um zu testen. Ich könnte mir durchaus auch vorstellen, dass ein Cookie Consent Banner Einfluss auf die Daten nehmen könnte…

Hiermit wollte ich allerdings erst einmal darstellen, wie Sie nutzerspezifische Erfahrungswerte in Form der Core Web Vitals sichtbar in einem Dashboard darstellen können. Für dieses kleine Beispiel habe ich die Daten einmalig exportiert. Wenn Sie die Daten automatisiert im Dashboard sehen möchten, müsste man mit Appscript in Google Sheets ein wenig arbeiten oder bei Bigquery mit automatisierten Routinen. Zudem fehlt die Differenzierung nach spezieller Seite und nach Gerätekategorie. Denn letztlich sollten Sie diese Metriken ja pro Seite ansehen und entsprechend handeln.

Filtern Sie dazu nach den häufigst besuchtesten Seiten und sehen sich die Web Vitals Werte an: Sind hier bei den 75% Perzentilen für desktop/mobile starke Ausreißer erkennbar? Dann ist hier der größte Optimierungsbedarf, bei dem Sie ansetzen sollten!

Fazit

Web-Vitals stellen einen großen Sprung in der Transparenz und im Verständnis der Web-Performance dar. Mit der Ankündigung von Google, dass sie in die Ranking-Signale einbezogen werden, sollten Web-Profis mit ihrer Arbeitsweise vertrauter werden. Google hat damit begonnen, diese Metriken in eine Vielzahl verschiedener Tools wie Page Insights und Search Console zu integrieren, was die Frage aufwirft: Warum sollte man sich überhaupt die Arbeit machen und die Daten auch noch zu Google Analytics senden?

Hier sind einige Gründe:

• Die Webvitals-Daten in der Search Console & des Chrome User Experience Reports basieren auf anonymen Nutzern, die beliebte Websites besuchen. Das bedeutet, dass Ihre Website oder eine bestimmte Seite auf Ihrer Website möglicherweise nicht in diesen Berichten erfasst wird.
• Das Page Insights-Tool liefert “Labor”-Daten in dem Sinne, dass seine Ergebnisse auf Softwareprüfungen basieren. Das Sammeln von Webvitals Daten von echten Benutzern liefert Daten “aus dem Leben “, die in bestimmten Fällen aussagekräftiger sein können.
• Durch das Sammeln dieser Daten in der GA können wir nach benutzerdefinierten Dimensionen segmentieren, wie z.B. “eingeloggte” Benutzer, “frühere Kunden” oder firmenspezifische Informationen wie “große Unternehmen”, um zu verstehen, wie unsere Website für unsere wertvollsten Benutzer funktioniert.
• Mit dem Zugang zu den Rohdaten können wir fortgeschrittenere Analysen und Diagramme wie die oben gezeigten erstellen. Dies ist eine enorme Verbesserung gegenüber den hoch verdichteten Daten, die von der Search Console bereitgestellt werden.

Ich hoffe, dass dieser Beitrag Ihnen die Möglichkeit gibt, die Leistung Ihrer Website zu verbessern und Ihre Positionen in der Google Suche zu verbessern.