Wie man Core Web Vitals Metriken mit GA & GTM misst

Web Vitals ist eine Initiative von Google, um einheitliche Richtlinien für Qualitätskennzahlen bereitzustellen, die für die Bereitstellung einer großartigen Benutzererfahrung im Web unerlässlich sind.

Im Mittelpunkt dieser Qualitätskennzahlen stehen die drei „Core Web Vitals“ Metriken:

• Largest Contentful Paint (LCP)
• First Input Delay (FID)
• Cumulative Layout Shift (CLS)

Obwohl alle drei nützlich sind, würde ich dir empfehlen, deine Analyse mit dem Largest Contentful Paint zu beginnen. Die Optimierung für LCP wird die größte absolute Verbesserung der wahrgenommenen Ladegeschwindigkeit bringen. Wenn das Laden deiner Website bereits langsam ist, wird es nicht viel helfen, wenn die Seite sofort interaktiv ist (FID) und das Layoutflimmern reduziert wird (CLS), um deine bereits genervten Nutzer zu beruhigen.

Jetzt ist der perfekte Zeitpunkt, um mit der Messung von Web Vitals zu beginnen, da es gerade viel einfacher geworden ist, seit Google kürzlich ihre web-vitals JavaScript-Bibliothek veröffentlicht hat, die die Berechnungen in eine praktische Blackbox packt, sodass wir uns nicht um die Details kümmern müssen.

Web Vitals werden bereits kostenlos in der Google Search Console erfasst

Google Search Console (GSC) ist Googles offizielles Webmaster-Kommunikationstool, in dem du viele Daten über die Leistung deiner Website in der Suche und andere Qualitätsindikatoren findest – jetzt auch einschließlich der drei Core Web Vitals! Das bedeutet, ohne etwas implementieren zu müssen, könntest du sofort mit der Optimierung beginnen, da du bereits die URLs mit besonders schlechter Seitengeschwindigkeit kennst.

Dennoch können die Web-Vitals-Messungen in der Google Search Console deine eigene Datenerfassung nicht ersetzen:

• Search Console zeigt keine Web Vitals Daten für alle Seiten deiner Website an
• Es gibt keine Metadaten in der GSC, die du verwenden könntest, um Seiten zu gruppieren und deine Daten zu aggregieren. Einige Aggregationen könnten basierend nur auf der URL funktionieren, wie das Filtern nach Vorlagen, da vielleicht deine /recipe/… Seiten eine Vorlage teilen, die besonders langsam lädt. Aggregationen, die zusätzliche Daten benötigen, z. B. nach Traffic (hoch, mittel, niedrig), können sehr nützlich sein, da du deine Seitengeschwindigkeitsoptimierung auf Seiten priorisieren möchtest, auf denen der Großteil deines Traffics davon profitieren kann. Im Moment ist dies in der GSC nicht möglich.
• Web Vitals in der GSC sind Messungen von echten Nutzern, nicht Googlebot, die Google als “Felddaten” bezeichnet. Das ist gut, aber nicht alle deine Nutzer sind in der GSC-Stichprobe vertreten: Nur diejenigen, die Teil des Chrome User Experience Report sind, können in der Search Console erscheinen, d. h. Nutzer mit einem Chrome-Browser, die sich entschieden haben, ihren Browserverlauf zu synchronisieren. Einige Web Vitals können auch in anderen Browsern gemessen werden, die nur gezählt würden, wenn du Web Vitals selbst misst.

Web Vitals in die dataLayer einfügen

Der Prozess ist:

1. Lade die web-vitals JavaScript-Bibliothek
2. Messe die drei Kernmetriken
3. Schiebe das Ergebnis in die dataLayer

Du kannst die webvitals-Bibliothek von einem CDN laden, wie in Web Vitals: Loading Web Vitals from a CDN beschrieben. Das ist okay, aber für die Produktion empfehle ich, das kleine Skript von https://unpkg.com/web-vitals@0.2.2/dist/web-vitals.es5.umd.min.js direkt in den GTM als Tag zu kopieren, so dass du nicht von den unpkg.com-Servern abhängig bist.

…javascript

…

Die Funktion sendToDataLayer wird als Callback verwendet, sodass sie ausgeführt wird, wann immer eine der Funktionen window.webVitals.get… abgeschlossen ist. Die fünf dort aufgeführten Funktionen sind alles, was die web-vitals Bibliothek unterstützt, du kannst gerne einige entfernen, wenn du nicht alle benötigst.

Du wirst feststellen, dass ich die Ereignisattribute aus der Dokumentation ein wenig geändert habe und die generischen „eventCategory“, „eventAction“ und „eventLabel“ durch spezifische Schlüssel ersetzt habe. Sieh dir meine Google Tag Manager Guidelines an, um zu sehen, warum das eine gute Idee ist.
Ich konvertiere auch den Metriknamen mit .toLowerCase(), einfach weil mir das Aussehen von “lcp” besser gefällt als “LCP” in meinen Ereignissen.

Google Tag Manager konfigurieren, um ein Google Analytics Ereignis zu senden

Wann immer eine der Messungen von unserem benutzerdefinierten HTML-Tag abgeschlossen ist, wird die resultierende webVitals dieses Google Analytics Tag auslösen. Dieses Tag sendet ein Ereignis an Google Analytics mit:

• der passend benannten Ereigniskategorie “webvitals”
• dem Namen der Metrik als Ereignisaktion und
• dem Ergebnis der Messung für diese Metrik als Ereigniswert

Das Ereignis sollte als Nicht-Interaktion-Ereignis konfiguriert werden, um zu verhindern, dass es unsere Absprungrate künstlich senkt.

Analyse in Google Analytics

Mit der obigen Implementierung kannst du die Messungen bereits sehen, wenn du den durchschnittlichen Ereigniswert betrachtest.