So messen Sie Web Vitals mit Ihrem aktuellen Analysetool.
Die Möglichkeit, die tatsächliche Leistung Ihrer Seiten zu messen und Berichte dazu zu erstellen, ist entscheidend, um die Leistung im Zeitverlauf zu diagnostizieren und zu verbessern. Ohne Felddaten können Sie nicht sicher sein, ob die von Ihnen an Ihrer Website vorgenommenen Änderungen tatsächlich die gewünschten Ergebnisse erzielen.
Viele beliebte Anbieter von Real User Monitoring (RUM) unterstützen die Core Web Vitals-Messwerte in ihren Tools bereits (ebenso wie viele andere Web Vitals). Wenn Sie derzeit eines dieser RUM-Analysetools verwenden, können Sie sehr gut beurteilen, inwiefern die Seiten Ihrer Website die empfohlenen Grenzwerte für Core Web Vitals einhalten, und Rückschritte in Zukunft verhindern.
Wir empfehlen zwar die Verwendung eines Analysetools, das die Core Web Vitals-Messwerte unterstützt, aber wenn das von Ihnen derzeit verwendete Analysetool diese nicht unterstützt, müssen Sie nicht unbedingt umsteigen. Fast alle Analysetools bieten die Möglichkeit, benutzerdefinierte Messwerte oder Ereignisse zu definieren und zu erfassen. Sie können also wahrscheinlich Ihren aktuellen Analyseanbieter verwenden, um die Core Web Vitals-Messwerte zu erfassen und sie Ihren vorhandenen Analyseberichten und Dashboards hinzuzufügen.
In diesem Leitfaden werden Best Practices für das Erfassen von Core Web Vitals-Messwerten (oder benutzerdefinierten Messwerten) mit einem Analysetool von Drittanbietern oder einem internen Analysetool beschrieben. Er kann auch als Leitfaden für Anbieter von Analysetools dienen, die ihren Dienst um Core Web Vitals-Unterstützung erweitern möchten.
Benutzerdefinierte Messwerte oder Ereignisse verwenden
Wie bereits erwähnt, können Sie mit den meisten Analysetools benutzerdefinierte Daten messen. Sofern Ihr Analysetool dies unterstützt, sollten Sie mit diesem Mechanismus alle Core Web Vitals-Messwerte messen können.
Das Erfassen benutzerdefinierter Messwerte oder Ereignisse in einem Analysetool erfolgt in der Regel in drei Schritten:
- Definieren oder registrieren Sie den benutzerdefinierten Messwert im Administratorbereich Ihres Tools (falls erforderlich). Hinweis: Bei einigen Analyseanbietern müssen benutzerdefinierte Messwerte nicht im Voraus definiert werden.
- Berechnen Sie den Wert des Messwerts in Ihrem Frontend-JavaScript-Code.
- Senden Sie den Messwert an Ihr Analyse-Back-End und achten Sie darauf, dass der Name oder die ID mit der Definition in Schritt 1 übereinstimmt (falls erforderlich).
Eine Anleitung für die Schritte 1 und 3 finden Sie in der Dokumentation Ihres Analysetools. Für Schritt 2 können Sie die JavaScript-Bibliothek web-vitals verwenden, um den Wert jedes der Core Web Vitals-Messwerte zu berechnen.
Das folgende Codebeispiel zeigt, wie einfach es ist, diese Messwerte im Code zu erfassen und an einen Analysedienst zu senden.
import {onCLS, onINP, onLCP} from 'web-vitals';
function sendToAnalytics({name, value, id}) {
const body = JSON.stringify({name, value, id});
// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
Durchschnittswerte vermeiden
Es ist verlockend, einen Wertebereich für einen Leistungsmesswert durch Berechnung eines Durchschnittswerts zusammenzufassen. Durchschnittswerte erscheinen auf den ersten Blick praktisch, da sie eine übersichtliche Zusammenfassung einer großen Datenmenge darstellen. Sie sollten sich jedoch nicht darauf verlassen, um die Seitenleistung zu interpretieren.
Durchschnittswerte sind problematisch, da sie nicht die Sitzung eines einzelnen Nutzers repräsentieren. Ausreißer in beiden Bereichen der Verteilung können den Durchschnitt auf irreführende Weise verfälschen.
Beispielsweise kann eine kleine Gruppe von Nutzern extrem langsame Netzwerke oder Geräte verwenden, die sich im oberen Bereich der Werte befinden. Es werden jedoch nicht genügend Nutzersitzungen berücksichtigt, um den Durchschnitt so zu beeinflussen, dass ein Problem vermutet wird.
Verwenden Sie nach Möglichkeit Perzentile anstelle von Durchschnittswerten. Prozentile in einer Verteilung für einen bestimmten Leistungsmesswert beschreiben die gesamte Bandbreite der Nutzerfreundlichkeit Ihrer Website besser. So können Sie sich auf Teilmengen der tatsächlichen Erfahrungen konzentrieren und erhalten mehr Informationen als ein einzelner Wert je möglich.
Sicherstellen, dass eine Verteilung gemeldet werden kann
Nachdem Sie die Werte für jeden Core Web Vitals-Messwert berechnet und mithilfe eines benutzerdefinierten Messwerts oder Ereignisses an Ihren Analysedienst gesendet haben, können Sie einen Bericht oder ein Dashboard erstellen, in dem die erfassten Werte angezeigt werden.
Damit Sie die empfohlenen Grenzwerte für Core Web Vitals einhalten, muss der Wert jedes Messwerts im Bericht den 75. Perzentilwert anzeigen.
Wenn Ihr Analysetool keine integrierte Funktion für Quantilberichte bietet, können Sie diese Daten wahrscheinlich trotzdem manuell abrufen, indem Sie einen Bericht erstellen, in dem alle Messwerte in aufsteigender Reihenfolge aufgeführt sind. Sobald dieser Bericht generiert wurde, entspricht das Ergebnis, das 75% der gesamten, sortierten Liste aller Werte in diesem Bericht durchlaufen hat, dem 75. Perzentil für diesen Messwert. Dies ist der Fall, unabhängig davon, wie Sie Ihre Daten segmentieren (nach Gerätetyp, Verbindungstyp, Land usw.).
Wenn Ihr Analysetool standardmäßig keine Berichtsgranularität auf Metrikebene bietet, können Sie wahrscheinlich dasselbe Ergebnis erzielen, wenn Ihr Analysetool benutzerdefinierte Dimensionen unterstützt. Wenn Sie für jede einzelne Messwertinstanz, die Sie erfassen, einen eindeutigen benutzerdefinierten Dimensionswert festlegen, sollten Sie einen Bericht erstellen können, der nach einzelnen Messwertinstanzen aufgeschlüsselt ist, sofern Sie die benutzerdefinierte Dimension in die Berichtskonfiguration aufnehmen. Da jede Instanz einen eindeutigen Dimensionswert hat, erfolgt keine Gruppierung.
Der Bericht „Web Vitals“ ist ein Beispiel für diese Methode, die Google Analytics verwendet. Der Code für den Bericht ist Open Source, sodass Entwickler ihn als Beispiel für die in diesem Abschnitt beschriebenen Techniken verwenden können.
Daten zum richtigen Zeitpunkt senden
Einige Leistungsmesswerte können berechnet werden, sobald die Seite vollständig geladen ist, während andere (z. B. CLS) die gesamte Lebensdauer der Seite in Betracht ziehen und erst dann endgültig sind, wenn der Seitenentladevorgang gestartet wurde.
Das kann jedoch problematisch sein, da sowohl das beforeunload- als auch das unload-Ereignis nicht zuverlässig sind (insbesondere auf Mobilgeräten) und ihre Verwendung nicht empfohlen wird, da sie verhindern können, dass eine Seite für den Back-Forward-Cache infrage kommt.
Bei Messwerten, die die gesamte Lebensdauer einer Seite erfassen, ist es am besten, immer dann den aktuellen Wert des Messwerts während des visibilitychange-Ereignisses zu senden, wenn sich der Sichtbarkeitsstatus der Seite zu hidden ändert. Das liegt daran, dass nach dem Ändern des Sichtbarkeitsstatus der Seite in hidden nicht garantiert werden kann, dass Scripts auf dieser Seite noch einmal ausgeführt werden können. Das gilt insbesondere für mobile Betriebssysteme, bei denen die Browser-App selbst geschlossen werden kann, ohne dass Seiten-Callbacks ausgelöst werden.
Hinweis: Bei mobilen Betriebssystemen wird das Ereignis visibilitychange in der Regel ausgelöst, wenn zwischen Tabs gewechselt, zwischen Apps gewechselt oder die Browser-App selbst geschlossen wird.
Außerdem wird das Ereignis visibilitychange ausgelöst, wenn ein Tab geschlossen oder eine neue Seite aufgerufen wird. Das macht das Ereignis visibilitychange wesentlich zuverlässiger als die Ereignisse unload oder beforeunload.
Leistung im Zeitverlauf analysieren
Nachdem du deine Analyseimplementierung so aktualisiert hast, dass die Core Web Vitals-Messwerte erfasst und Berichte dazu erstellt werden, kannst du im nächsten Schritt verfolgen, wie sich Änderungen an deiner Website im Laufe der Zeit auf die Leistung auswirken.
Änderungen versionieren
Ein naiver (und letztendlich unzuverlässiger) Ansatz zum Überwachen von Änderungen besteht darin, Änderungen in der Produktion bereitzustellen und dann davon auszugehen, dass alle Messwerte, die nach dem Bereitstellungsdatum erfasst werden, der neuen Website und alle Messwerte, die vor dem Bereitstellungsdatum erfasst werden, der alten Website entsprechen. Es gibt jedoch eine Reihe von Faktoren (z. B. Caching auf HTTP-, Service Worker- oder CDN-Ebene), die dies verhindern können.
Es ist viel besser, für jede bereitgestellte Änderung eine eindeutige Version zu erstellen und diese Version dann in Ihrem Analysetool zu erfassen. Die meisten Analysetools unterstützen das Festlegen einer Version. Falls nicht, können Sie eine benutzerdefinierte Dimension erstellen und für Ihre bereitgestellte Version festlegen.
Tests durchführen
Sie können die Versionierung noch weiter optimieren, indem Sie mehrere Versionen (oder Tests) gleichzeitig erfassen.
Verwenden Sie diese Funktion, wenn Sie mit Ihrem Analysetool Testgruppen definieren können. Andernfalls können Sie benutzerdefinierte Dimensionen verwenden, damit jeder Messwert in Ihren Berichten einer bestimmten Testgruppe zugeordnet werden kann.
Wenn Sie Tests in Ihren Analysen eingerichtet haben, können Sie eine Teständerung für eine Teilmenge Ihrer Nutzer einführen und die Leistung dieser Änderung mit der Leistung der Nutzer in der Kontrollgruppe vergleichen. Sobald Sie sich sicher sind, dass eine Änderung die Leistung tatsächlich verbessert, können Sie sie für alle Nutzer einführen.
Dafür sorgen, dass sich die Messung nicht auf die Leistung auswirkt
Wenn Sie die Leistung bei echten Nutzern messen, ist es absolut entscheidend, dass der Code zur Leistungsmessung die Leistung Ihrer Seite nicht negativ beeinflusst. In diesem Fall sind alle Schlussfolgerungen, die Sie zur Auswirkung Ihrer Leistung auf Ihr Unternehmen ziehen, nicht zuverlässig, da Sie nie wissen werden, ob der Analytics-Code selbst die größte negative Auswirkung hat.
Halten Sie sich immer an diese Prinzipien, wenn Sie RUM-Analysecode auf Ihrer Produktionswebsite bereitstellen:
Analysen verschieben
Der Analytics-Code sollte immer asynchron und nicht blockierend geladen werden. Im Allgemeinen sollte er zuletzt geladen werden. Wenn Sie Ihren Analytics-Code blockierend laden, kann sich das negativ auf den LCP auswirken.
Alle APIs, die zum Erfassen der Core Web Vitals-Messwerte verwendet werden, wurden speziell für das asynchrone und verzögerte Script-Laden (über das Flag buffered) entwickelt. Es ist also nicht nötig, Ihre Scripts frühzeitig zu laden.
Wenn Sie einen Messwert erfassen, der später im Zeitverlauf des Seitenladevorgangs nicht berechnet werden kann, sollten Sie nur den Code, der früh ausgeführt werden muss, in die <head> Ihres Dokuments einfügen (damit es sich nicht um eine renderblockierende Anfrage handelt) und den Rest verschieben. Laden Sie nicht alle Analysen frühzeitig, nur weil ein einzelner Messwert dies erfordert.
Keine langen Aufgaben erstellen
Analytics-Code wird häufig als Reaktion auf Nutzereingaben ausgeführt. Wenn Ihr Analytics-Code jedoch viele DOM-Messungen durchführt oder andere prozessorintensive APIs verwendet, kann der Analytics-Code selbst zu einer schlechten Eingabereaktion führen. Wenn die JavaScript-Datei mit Ihrem Analysecode groß ist, kann die Ausführung dieser Datei den Hauptthread blockieren und sich negativ auf die Interaktion bis zur nächsten Darstellung (Interaction to Next Paint, INP) einer Seite auswirken.
Nicht blockierende APIs verwenden
APIs wie sendBeacon() und requestIdleCallback() wurden speziell dafür entwickelt, nicht kritische Aufgaben so auszuführen, dass nutzerkritische Aufgaben nicht blockiert werden.
Diese APIs eignen sich hervorragend für eine RUM-Analysebibliothek.
Im Allgemeinen sollten alle Analytics-Beacons über die sendBeacon() API (falls verfügbar) gesendet und der gesamte Code zur passiven Analyse während der Inaktivität ausgeführt werden.
Nicht mehr erfassen, als Sie benötigen
Der Browser stellt viele Leistungsdaten bereit. Nur weil die Daten verfügbar sind, heißt das aber nicht unbedingt, dass Sie sie aufzeichnen und an Ihre Analyseserver senden sollten.
Die Resource Timing API bietet beispielsweise detaillierte Zeitdaten für jede einzelne Ressource, die auf Ihrer Seite geladen wird. Es ist jedoch unwahrscheinlich, dass alle diese Daten zur Verbesserung der Ressourcenladeleistung erforderlich oder nützlich sind.
Kurz gesagt: Erfassen Sie Daten nicht nur, weil sie verfügbar sind. Achten Sie darauf, dass die Daten verwendet werden, bevor Sie Ressourcen für das Tracking aufwenden.