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 Laufe der Zeit 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 erfassen. Wenn Ihr Analysetool dies unterstützt, sollten Sie alle Core Web Vitals-Messwerte mit diesem Mechanismus erfassen 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 vorab definiert werden.
- Berechnen Sie den Wert des Messwerts in Ihrem Frontend-JavaScript-Code.
- Senden Sie den Messwert an Ihr Analytics-Backend. Achten Sie darauf, dass der Name oder die ID mit den in Schritt 1 definierten Werten übereinstimmt. Wiederholen Sie diesen Schritt bei Bedarf.
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 mit extrem langsamen Netzwerken oder Geräten, die sich im oberen Bereich der Werte befinden, nicht genügend Nutzersitzungen umfassen, um sich auf den Durchschnitt so auszuwirken, 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 von tatsächlichen Erfahrungen konzentrieren, was Ihnen mehr Einblicke bietet als ein einzelner Wert.
Voraussetzungen für die Meldung einer Verbreitung
Nachdem Sie die Werte für jeden der Core Web Vitals-Messwerte berechnet und sie über einen benutzerdefinierten Messwert oder ein benutzerdefiniertes Ereignis an Ihren Analysedienst gesendet haben, erstellen Sie einen Bericht oder ein Dashboard mit den erfassten Werten.
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. Nach der Generierung dieses Berichts entspricht der Wert an der 75 %-Position der sortierten Liste aller Werte in diesem Bericht dem 75. Perzentil für diesen Messwert. Das ist unabhängig davon, wie Sie Ihre Daten segmentieren (z. B. nach Gerätetyp, Verbindungstyp oder Land).
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 Messwertinstanz, die Sie erfassen, einen eindeutigen Wert für die benutzerdefinierte Dimension festlegen, sollten Sie einen Bericht mit einer Aufschlüsselung nach einzelnen Messwertinstanzen generieren können, wenn 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. Entwickler können ihn als Beispiel für die in diesem Abschnitt beschriebenen Techniken verwenden.
Daten zum richtigen Zeitpunkt senden
Einige Leistungsmesswerte können berechnet werden, sobald der Seitenaufbau abgeschlossen ist. Andere (z. B. CLS) berücksichtigen die gesamte Lebensdauer der Seite und sind erst endgültig, wenn der Seitenentladevorgang begonnen hat.
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, sollten Sie den aktuellen Wert des Messwerts während des Ereignisses visibilitychange senden, wenn sich der Sichtbarkeitsstatus der Seite in 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. Dies 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 Sie Ihre Analyseimplementierung aktualisiert haben, um die Core Web Vitals-Messwerte zu erfassen und zu erfassen, ist der nächste Schritt, zu verfolgen, wie sich Änderungen an Ihrer 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.
Wenn Sie in Ihrem Analysetool Testgruppen definieren können, sollten Sie diese Funktion verwenden. 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 die Messung die Leistung nicht beeinträchtigt
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.
Beachten Sie beim Bereitstellen von RUM-Analysecode auf Ihrer Produktionswebsite immer die folgenden Prinzipien:
Analysen verschieben
Analytics-Code sollte immer asynchron und nicht blockierend geladen werden und im Allgemeinen als Letztes. 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() sind speziell für die Ausführung nicht kritischer Aufgaben konzipiert, die nicht blockieren, wenn Nutzer wichtige Aufgaben ausführen.
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 für die passive Analyse während der Inaktivität ausgeführt werden.
Nicht mehr erfassen, als Sie benötigen
Der Browser stellt viele Leistungsdaten bereit. Das bedeutet aber nicht unbedingt, dass Sie sie erfassen 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.