So messen Sie Web Vitals mit Ihrem aktuellen Analysetool.
Die Fähigkeit, die tatsächliche Leistung Ihrer Seiten zu messen und Berichte dazu zu erstellen, ist für die Diagnose und Verbesserung der Leistung im Laufe der Zeit von entscheidender Bedeutung. Ohne Felddaten lässt sich nicht mit Sicherheit feststellen, ob die Änderungen, die Sie an Ihrer Website vornehmen, auch wirklich zu den gewünschten Ergebnissen führen.
Viele gängige Anbieter von Real User Monitoring (RUM) unterstützen bereits die Core Web Vitals-Messwerte in ihren Tools sowie viele andere Web Vitals. Wenn Sie derzeit eines dieser RUM-Analysetools verwenden, können Sie ganz gut einschätzen, wie gut die Seiten Ihrer Website die empfohlenen Core Web Vitals-Grenzwerte erfüllen, und künftige Regressionen verhindern.
Wir empfehlen zwar die Verwendung eines Analysetools, das die Core Web Vitals-Messwerte unterstützt. Wenn das von Ihnen verwendete Analysetool diese aber nicht unterstützt, müssen Sie nicht unbedingt wechseln. Fast alle Analysetools bieten die Möglichkeit, benutzerdefinierte Messwerte oder Ereignisse zu definieren und zu messen. Das bedeutet, dass Sie wahrscheinlich Ihren derzeitigen Analyseanbieter verwenden können, um die Core Web Vitals-Messwerte zu messen und in Ihre vorhandenen Analyseberichte und Dashboards aufzunehmen.
In diesem Leitfaden werden Best Practices für die Messung von Core Web Vitals-Messwerten (oder benutzerdefinierten Messwerten) mit einem internen oder Drittanbieter-Analysetool erläutert. Sie kann auch als Leitfaden für Anbieter von Analysen dienen, die ihren Dienst um Core Web Vitals ergänzen möchten.
Benutzerdefinierte Messwerte oder Ereignisse verwenden
Wie bereits erwähnt, können Sie mit den meisten Analysetools benutzerdefinierte Daten messen. Wenn Ihr Analysetool dies unterstützt, sollten Sie alle Core Web Vitals-Messwerte mithilfe dieses Mechanismus messen können.
Das Messen benutzerdefinierter Messwerte oder Ereignisse in einem Analysetool erfolgt in der Regel in drei Schritten:
- Definieren oder registrieren Sie den benutzerdefinierten Messwert beim Administrator des Tools (falls erforderlich). Hinweis: Nicht alle Analyseanbieter verlangen, dass benutzerdefinierte Messwerte im Voraus definiert werden.
- Berechnen Sie den Messwert im Front-End-JavaScript-Code.
- Senden Sie den Messwert an Ihr Analyse-Back-End. Achten Sie dabei darauf, dass der Name oder die ID mit der Definition in Schritt 1 übereinstimmt (gegebenenfalls auch noch einmal).
Eine Anleitung für die Schritte 1 und 3 finden Sie in der Dokumentation Ihres Analysetools. In Schritt 2 kannst du die JavaScript-Bibliothek web-vitals verwenden, um den Wert jedes Core Web Vitals-Messwerts zu berechnen.
Das folgende Codebeispiel zeigt, wie einfach es ist, diese Messwerte im Code zu verfolgen und an einen Analysedienst zu senden.
import {onCLS, onFID, 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);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);
Durchschnittswerte vermeiden
Es ist verlockend, einen Wertebereich für einen Leistungsmesswert durch die Berechnung eines Durchschnitts zusammenzufassen. Durchschnittswerte sind auf den ersten Blick praktisch, da sie eine übersichtliche Zusammenfassung einer großen Datenmenge sind. Sie sollten sich jedoch nicht auf sie verlassen, um die Seitenleistung zu interpretieren.
Durchschnitte sind problematisch, da sie nicht die Sitzung eines einzelnen Nutzers repräsentieren. Ausreißer in beiden Bereichen der Verteilung können den Durchschnitt in irreführender Weise verzerren.
So kann es beispielsweise sein, dass eine kleine Gruppe von Nutzern extrem langsame Netzwerke oder Geräte verwendet, die zwar den maximalen Wertebereich erreichen, aber nicht genügend Nutzersitzungen berücksichtigt werden, um den Durchschnitt auf eine Weise zu beeinflussen, die auf ein Problem hindeutet.
Verwenden Sie nach Möglichkeit Perzentile statt Durchschnittswerte. Perzentile innerhalb einer Verteilung für einen bestimmten Leistungsmesswert beschreiben besser die gesamte Bandbreite der Nutzererfahrung auf Ihrer Website. So können Sie sich auf Teilmengen der tatsächlichen Erfahrungen konzentrieren und erhalten so mehr Informationen, als ein einzelner Wert jemals möglich wäre.
Sicherstellen, dass Sie eine Verteilung melden können
Nachdem Sie die Werte für alle Core Web Vitals-Messwerte berechnet und sie mithilfe eines benutzerdefinierten Messwerts oder Ereignisses an Ihren Analysedienst gesendet haben, müssen Sie als Nächstes einen Bericht oder ein Dashboard mit den erfassten Werten erstellen.
Damit Sie die empfohlenen Core Web Vitals-Grenzwerte erfüllen, muss Ihr Bericht den Wert jedes Messwerts beim 75. Perzentil enthalten.
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 aufgelistet sind. Sobald dieser Bericht erstellt wurde, ist das Ergebnis, das 75% der vollständigen, sortierten Liste aller Werte in diesem Bericht das 75. Perzentil für diesen Messwert darstellt. Dies ist unabhängig davon, wie Sie Ihre Daten segmentieren (nach Gerätetyp, Verbindungstyp, Land usw.).
Wenn Ihr Analysetool standardmäßig keinen Detaillierungsgrad für Berichte auf Messwertebene bietet, können Sie wahrscheinlich dasselbe Ergebnis erzielen, wenn das Analysetool benutzerdefinierte Dimensionen unterstützt. Wenn Sie für jede einzelne Messwertinstanz, die Sie erfassen, einen eindeutigen Wert für benutzerdefinierte Dimensionen festlegen, sollten Sie einen Bericht erstellen können, der nach einzelnen Messwertinstanzen aufgeschlüsselt ist, wenn Sie die benutzerdefinierte Dimension in die Berichtskonfiguration aufnehmen. Da jede Instanz einen eindeutigen Dimensionswert hat, erfolgt keine Gruppierung.
Der Web Vitals-Bericht ist ein Beispiel für dieses Verfahren, bei dem Google Analytics zum Einsatz kommt. 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 zur richtigen Zeit senden
Einige Leistungsmesswerte können berechnet werden, sobald der Ladevorgang der Seite abgeschlossen ist, während andere (z. B. CLS) die gesamte Lebensdauer der Seite berücksichtigen und erst dann endgültig sind, wenn der Ladevorgang der Seite begonnen hat.
Dies kann jedoch problematisch sein, da die Ereignisse beforeunload und unload nicht zuverlässig sind (insbesondere auf Mobilgeräten) und nicht empfohlen werden, da eine Seite sonst möglicherweise nicht für den Back-Forward-Cache verwendet werden kann.
Bei Messwerten, die die gesamte Lebensdauer einer Seite erfassen, empfiehlt es sich, immer dann den aktuellen Messwert des Messwerts während des Ereignisses visibilitychange zu senden, wenn sich der Sichtbarkeitsstatus der Seite in hidden ändert. Sobald sich der Sichtbarkeitsstatus der Seite in hidden ändert, gibt es nämlich keine Garantie dafür, dass ein Script auf dieser Seite noch einmal ausgeführt werden kann. Dies gilt insbesondere für mobile Betriebssysteme, bei denen die Browser-App geschlossen werden kann, ohne dass Seiten-Callbacks ausgelöst werden.
Beachten Sie, dass mobile Betriebssysteme in der Regel das visibilitychange-Ereignis auslösen, wenn zwischen Tabs und Apps gewechselt wird oder wenn die Browser-App selbst geschlossen wird.
Außerdem lösen sie das visibilitychange-Ereignis aus, wenn sie einen Tab schließen oder zu einer neuen Seite wechseln. Dadurch wird das visibilitychange-Ereignis viel zuverlässiger als das unload- oder beforeunload-Ereignis.
Leistung im Zeitverlauf analysieren
Nachdem Sie Ihre Analyseimplementierung aktualisiert haben, um Core Web Vitals-Messwerte zu erfassen und Berichte dazu zu erstellen, sollten Sie als Nächstes beobachten, wie sich Änderungen an Ihrer Website im Laufe der Zeit auf die Leistung auswirken.
Version der Änderungen
Ein naiver (und letztlich unzuverlässiger) Ansatz zur Verfolgung von Änderungen besteht darin, Änderungen an der Produktion bereitzustellen und dann davon auszugehen, dass alle nach dem Bereitstellungsdatum empfangenen Messwerte der neuen Website und alle vor dem Bereitstellungsdatum empfangenen Messwerte der alten Website entsprechen. Dies kann jedoch durch verschiedene Faktoren verhindert werden, z. B. das Caching auf der HTTP-, Service Worker- oder CDN-Ebene.
Ein wesentlich besserer Ansatz besteht darin, für jede bereitgestellte Änderung eine eindeutige Version zu erstellen und diese Version dann in Ihrem Analysetool zu verfolgen. Die meisten Analysetools unterstützen das Festlegen einer Version. Andernfalls können Sie eine benutzerdefinierte Dimension erstellen und diese auf die bereitgestellte Version festlegen.
Tests durchführen
Sie können die Versionsverwaltung noch einen Schritt weiter gehen, indem Sie mehrere Versionen (oder Tests) gleichzeitig erfassen.
Wenn Sie mit Ihrem Analysetool Testgruppen definieren können, verwenden Sie diese Funktion. Andernfalls können Sie mithilfe von benutzerdefinierten Dimensionen dafür sorgen, dass jeder Messwert in Ihren Berichten einer bestimmten Testgruppe zugeordnet werden kann.
Wenn Sie Tests in Ihren Analysen durchgeführt haben, können Sie eine experimentelle Änderung für eine Teilmenge Ihrer Nutzer einführen und die Leistung dieser Änderung mit der Leistung der Nutzer in der Kontrollgruppe vergleichen. Wenn Sie sicher sind, dass eine Änderung die Leistung verbessert, können Sie sie für alle Nutzer einführen.
Sicherstellen, dass die Messung die Leistung nicht beeinträchtigt
Wenn Sie die Leistung an echten Nutzern messen, sollten Sie unbedingt darauf achten, dass sich jeglicher Code zur Leistungsmessung, den Sie ausführen, nicht negativ auf die Leistung Ihrer Seite auswirkt. Wenn dies der Fall ist, sind alle Schlussfolgerungen, die Sie aus der Auswirkung Ihrer Leistung auf Ihr Unternehmen ziehen möchten, unzuverlässig, da Sie nie wissen, ob das Vorhandensein des Analysecodes selbst die größten negativen Auswirkungen hat.
Befolgen Sie immer diese Prinzipien, wenn Sie RUM-Analysecode auf Ihrer Produktionswebsite bereitstellen:
Analysen auf später verschieben
Der Analysecode sollte immer asynchron und nicht blockierend geladen werden und in der Regel als Letztes geladen werden. Wenn Ihr Analysecode blockiert wird, kann sich dies negativ auf den LCP auswirken.
Alle APIs, die zur Messung der Core Web Vitals-Messwerte verwendet werden, wurden speziell für asynchrones und verzögertes Laden von Skripts (über das Flag buffered) entwickelt. Sie müssen also nicht überstürzt werden, um Ihre Skripts frühzeitig laden zu lassen.
Falls Sie einen Messwert messen, der später in der Zeitleiste für den Seitenaufbau nicht berechnet werden kann, sollten Sie nur den Code, der vor Beginn des <head> Ihres Dokuments ausgeführt werden muss, inline einfügen und den Rest verschieben. Laden Sie nicht alle Analysen vorzeitig, nur weil dies für einen einzelnen Messwert erforderlich ist.
Keine langen Aufgaben erstellen
Der Analysecode wird häufig als Reaktion auf Nutzereingaben ausgeführt. Wenn Ihr Analysecode jedoch viele DOM-Messungen durchführt oder andere prozessorintensive APIs verwendet, kann der Analysecode selbst zu einer schlechten Reaktionsfähigkeit bei Eingaben führen. Wenn die JavaScript-Datei mit Ihrem Analysecode groß ist, kann das Ausführen dieser Datei außerdem den Hauptthread blockieren und sich negativ auf First Input Delay (FID) oder Interaction to Next Paint (INP) 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 die Verwendung in einer RUM-Analysebibliothek.
Im Allgemeinen sollten alle Beacons für Analysen über die sendBeacon() API gesendet werden (falls verfügbar) und der gesamte Code für die passive Analyse von Messwerten sollte während der Inaktivität ausgeführt werden.
Nicht mehr als nötig aufzeichnen
Der Browser stellt viele Leistungsdaten bereit. Nur weil die Daten verfügbar sind, bedeutet 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 unbedingt oder nützlich zur Verbesserung der Lastleistung der Ressourcen sind.
Kurz gesagt: Erfassen Sie die Daten nicht nur, weil sie vorhanden sind, sondern achten Sie darauf, dass die Daten verwendet werden, bevor Sie Ressourcen für die Nachverfolgung verbrauchen.