Hier erfahren Sie, warum in RUM-Daten unter Umständen andere Core Web Vitals-Werte als bei CrUX-Daten angezeigt werden.
Der Bericht zur Nutzererfahrung in Chrome (Chrome User Experience, CrUX) enthält Messwerte zur Nutzererfahrung, die Aufschluss darüber geben, wie echte Chrome-Nutzer beliebte Websites verwenden. Diese Daten werden von Chrome automatisch von Nutzern erhoben, die der Verwendung zugestimmt haben, und werden gemäß den Voraussetzungen für die Nutzererfahrung in Chrome zur Verfügung gestellt.
CrUX-Daten stehen daher für Millionen von Websites zur Verfügung. Viele Websiteinhaber hatten bisher noch keinen Zugriff auf Felddaten und dank CrUX konnten viele Websites zum ersten Mal von diesen Vorteilen profitieren. Als öffentliches Dataset kann CrUX auch für die Wettbewerbsanalyse und das Benchmarking von Messwerten zur Nutzererfahrung verwendet werden.
Real User Monitoring (RUM) ähnelt CrUX, aber statt Chrome wird nicht automatisch Messwerte zur Nutzererfahrung erfasst. Stattdessen wird Code auf den Websites eingefügt, um die Erfassung durchzuführen und ihn zur weiteren Analyse an einen RUM-Anbieter oder eine Analyselösung zurückzugeben.
Bei beiden Lösungen, mit denen Messwerte zur Nutzererfahrung gemessen werden, kann davon ausgegangen werden, dass die Messwerte äquivalent sein sollten. Es kann verwirrend sein, wenn wir Unterschiede feststellen. In diesem Leitfaden erfahren Sie, warum das passieren kann und was Sie tun können, wenn die Zahlen nicht übereinstimmen.
Vorteile der Ergänzung von CrUX durch eine RUM-Lösung
CrUX ist ein hervorragendes Tool für eine einheitliche Darstellung aller Websites. Da es sich bei Websites um den offiziellen Datensatz für das Core Web Vitals-Programm handelt, ist es wahrscheinlich, dass Websites im Blick behalten möchten, was angezeigt wird. Ziel von CrUX ist es, einen statistisch relevanten Überblick über Millionen von Websites zum Vergleich zu erhalten.
Wenn Sie jedoch genauer untersuchen möchten, warum Daten die Zahlen zeigen, können Sie in eine vollständige RUM-Lösung als Ergänzung zu CrUX investieren, um Zugriff auf detailliertere Informationen zu erhalten, die in einem öffentlich abfragbaren Dataset zur Verfügung gestellt werden könnten. Dies kann Ihnen dabei helfen, Ihre Messwerte auf verschiedene Weise zu erklären und zu verbessern.
Detailliertere Analysen zur Untersuchung von Problemen
Mithilfe von CrUX können Sie häufig auf ein Problem auf Ihrer Website hinweisen, aber nicht unbedingt genau, wo auf Ihrer Website das Problem liegt und warum. RUM-Lösungen – ob aus einer Web-Vitals-Bibliothek oder einigen der vielen kommerziellen Produkte – können helfen, diese Lücke zu schließen.
Mit einer RUM-Lösung erhalten Sie Zugriff auf wesentlich detailliertere Daten für alle Ihre Seiten und in allen Browsern. Außerdem lassen sich diese Daten auf eine Weise segmentieren und analysieren, die in der Nutzererfahrung in Chrome nicht möglich ist. So können Sie Problembereiche der Website aufschlüsseln und untersuchen. Sind sie von einem bestimmten Nutzersegment betroffen? Oder Nutzende, die bestimmte Aktionen ausführen? Wann genau ist das Problem erstmals aufgetreten? Diese Fragen lassen sich aufgrund der zusätzlichen Daten, die ein RUM-Tool liefern kann, viel einfacher beantworten.
Korrelation mit anderen Geschäftsmesswerten
Mit RUM können Sie die Messwerte zur Leistung Ihrer Website direkt mit anderen Unternehmensmesswerten vergleichen. So sehen Sie, welchen Wert eine Investition in die Leistung bringt und welche anderen Leistungsfaktoren Priorität haben sollten. Uns liegen zahlreiche Fallstudien von Unternehmen vor, die diese Korrelation nutzen, z. B. Farfetch oder The Economic Times.
Weitere Leistungsdaten erfassen
Eine RUM-Lösung ermöglicht die Erfassung anderer benutzerdefinierter Messwerte, die direkt mit Ihrem spezifischen Unternehmen verbunden sind. Eines der bekannteren Beispiele ist der Bericht „Time to first Tweet“ (Zeit für den ersten Tweet) von Twitter. Messwert. Diese websitespezifischen Maßnahmen können dann mit Core Web Vitals-Verbesserungen und Geschäftsmesswerten in Beziehung gesetzt werden.
Unterschiede zwischen zwei Sätzen von Felddaten
Ein Mann mit einer Uhr weiß, wie spät es ist. Bei einem Mann mit zwei Uhren ist man sich nie sicher.
Segalsches Gesetz
Immer wenn Sie zwei Datenquellen haben, kann es oft verwirrend und frustrierend sein, deren Gründe sich voneinander unterscheiden. Es ist nicht nur wichtig, den Unterschied zwischen Lab- und Feldmesswerten zu verstehen, sondern auch zwischen zwei Quellen von Felddaten. Obwohl die Daten in einer idealen Welt die gleichen wären, gibt es viele Gründe, warum sie sich unterscheiden können.
Labdaten und Felddaten im Vergleich
Zuerst müssen Sie prüfen, ob Sie sich die synthetischen Lab-Messwerte oder die RUM-Messwerte (Feldmesswerte) ansehen. Es ist zwar normal, dass RUM-Produkte nur Felddaten betrachten, viele bieten aber auch eine Lab-Komponente.
Labdaten sind aufgrund der festen Bedingungen, unter denen sie gemessen werden, unglaublich nützlich. Sie kann verwendet werden, um unerwartete Änderungen oder Regressionen in einer Produktionsumgebung ohne das Rauschen einer sich ändernden Feldpopulation zu überwachen. Die Lab-Daten sind jedoch möglicherweise nicht repräsentativ für die tatsächliche Nutzererfahrung, sodass Feldmesswerte sehr unterschiedliche Ergebnisse liefern können.
Bevölkerungsgruppen
Die Datensätze, die von CrUX- und RUM-Lösungen verwendet werden, können sich unterscheiden, da Seitenaufrufe je nachdem, welche Browser, Nutzer, Websites und Geräte verglichen werden, unterschiedlich gemessen werden.
Enthaltene Browser
Wie der Name schon sagt, ist der Bericht zur Nutzererfahrung in Chrome ausschließlich für Chrome verfügbar. Es gibt zwar viele Chromium-basierte Browser (z. B. Edge, Opera und Brave), die aufgrund der gemeinsamen zentralen Codebasis auch dieselben Messwerte wie Chrome unterstützen, aber nur Chrome-Nutzer speisen Daten in CrUX ein. Diese Einschränkung bedeutet auch, dass Chrome-Nutzer unter iOS nicht berücksichtigt werden, da sie die zugrunde liegende WebKit-Browser-Engine verwendet. Android WebViews zählen ebenfalls nicht als „Chrome“. Die Daten dieser Nutzer sind also nicht enthalten, obwohl benutzerdefinierte Chrome-Tabs enthalten sind.
Chrome ist zwar einer der beliebtesten Browser der Welt und würde daher in den meisten Fällen wahrscheinlich einen umfassenden Überblick über die Leistung Ihrer Website geben. Bei der Messung dieses Browsers handelt es sich jedoch keineswegs um ein Maß für Ihre Nutzer. Dies kann einen Hauptunterschied zwischen RUM und CrUX erklären. Dies gilt insbesondere für Leistungstechniken, die auf APIs oder Bildformaten basieren, die nur in Chrome verfügbar sind.
Das Fehlen von iOS-Daten kann ebenfalls zu Verzerrungen führen. Da iOS-Nutzer beispielsweise in der Regel leistungsstärkere Geräte verwenden oder sie aus mehr Ländern mit besserer Netzwerkinfrastruktur besuchen, kann dies zu hohen Gesamtleistungen führen. Wenn Sie sie jedoch ausschließen – wie bei CrUX –, können Daten zu Daten führen, die sich auf die unteren Besucherzahlen der Website konzentrieren (Beispielfallstudie). Android-Nutzer decken in der Regel ein breiteres Spektrum an Geräten, Gerätefunktionen und Märkten ab.
RUM-Lösungen können Daten von anderen Browsern als Chrome abrufen, insbesondere von Chromium-basierten Browsern, die oft dieselben Messwerte (z. B. Core Web Vitals) enthalten. Browser, die nicht auf Chromium basieren, werden auch von RUM-Lösungen gemessen, die Anzahl der Messwerte ist jedoch möglicherweise begrenzt. Cumulative Layout Shift (CLS) und Interaction to Next Paint (INP) sind beispielsweise nur in Chromium-basierten Browsern verfügbar. Einige andere Messwerte wie First Contentful Paint (FCP) können sehr unterschiedlich gemessen werden (siehe weiter unten).
Angemeldete Nutzer
CrUX ist nicht nur auf Chrome-Nutzer beschränkt, sondern wird weiter eingeschränkt, da nur ein Teil der Chrome-Nutzer erfasst werden, die sich bei der Installation des Browsers der Weitergabe von CrUX-Daten zugestimmt haben.
RUM-Anbieter berücksichtigen auch nur einen Teil der Nutzer. Dies geschieht in der Regel aufgrund von Cookie-Banner-Aufforderungen, in denen Nutzer aufgefordert werden, die RUM-Datenerhebung zu aktivieren, oder Tracking-Blocker. Dies kann sich nachteilig auf einige anfängliche Seitenladevorgänge auswirken, wenn die Bestätigung erst auf der zweiten oder nachfolgenden Seite erfolgt und einige der Website-Assets bereits von vorherigen Seiten im Cache gespeichert wurden. Tritt dies häufig auf, erscheinen die Messwerte in RUM möglicherweise besser als tatsächlich, wenn langsamere anfängliche Seitenladevorgänge in einer ausreichenden Anzahl von Fällen ausgeschlossen werden.
Eingeschlossene Websites
Mit CrUX werden nur Berichte zu öffentlichen Websites erstellt. Es gibt also weitere Voraussetzungen, die dazu führen können, dass Daten nicht in CrUX protokolliert werden. Das Wichtigste an diesen Kriterien ist, dass die Website öffentlich zugänglich und beliebt sein muss, um eine minimale Stichprobengröße sicherzustellen, aus der sich aussagekräftige Schlussfolgerungen ziehen lassen. In den meisten Fällen führt dies dazu, dass keine Daten in CrUX verfügbar sind. Dieser Unterschied ist im Vergleich zu den verfügbaren, aber unterschiedlichen Daten weniger verwirrend, erklärt aber auch die Gründe dafür.
Wenn jedoch bestimmte Seiten einer Website als „indexierbar“ gekennzeichnet sind, andere aber nicht, sehen Sie in CrUX möglicherweise nur einen Teil der URLs. Wenn der Ursprung öffentlich sichtbar ist, werden alle Seitenaufrufe innerhalb dieses Ursprungs in den Daten auf Ursprungsebene berücksichtigt. Daten auf URL-Ebene sind jedoch möglicherweise nicht verfügbar.
Geräte
In CrUX werden Daten nach Smartphones, Computern und Tablets segmentiert. Viele Tools konzentrieren sich jedoch auf die ersten beiden Tools und erheben möglicherweise keine Tablet-Daten oder auch für Mobilgeräte oder Computer. Die Leistungsmerkmale von Mobilgeräten und Desktop-Computern können sehr unterschiedlich sein – sowohl hinsichtlich der bereitgestellten Inhalte als auch hinsichtlich der Funktionen der Geräte, auf denen sie wiedergegeben werden.
RUM-Daten ermöglichen eine ähnliche Segmentierung des Traffics, enthalten jedoch häufig standardmäßig konsolidierte Daten. In RUM ist möglicherweise nur eine Segmentierung nach Gerätetyp (z. B. Mobilgerät) oder Browser (z. B. Chrome) zulässig, aber nicht nach beiden, um nur den mobilen Chrome-Traffic zu sehen. Achten Sie beim Vergleich mit CrUX-Daten darauf, dass sie auf ähnliche Weise verglichen werden. Filtern Sie dazu nach Gerätetyp und Chrome-Browser.
Probenahme
RUM-Lösungen ermöglichen in der Regel die Anpassung der Stichprobenrate von angemeldeten Besuchern, bei denen Daten erhoben werden. Dies kann verwendet werden, um das zu analysierende Datenvolumen zu reduzieren und die Kosten kommerzieller RUM-Dienste zu senken. Wenn diese Stichprobengröße zu klein und nicht repräsentativ für die breitere Population ist, sind die resultierenden Messwerte ebenfalls ähnlich verzerrt. Besprechen Sie mit Ihrem RUM-Anbieter die geeignete Stichprobengröße für Ihre Website.
Datenaggregation
Felddaten enthalten naturgemäß viele Datenpunkte mit denselben Messwerten, im Vergleich zu Labordaten, die einen einzelnen Wert ergeben. Wenn diese Daten für die Berichterstellung unterschiedlich aggregiert werden, kann dies zu einem anderen Grund für Unterschiede zwischen CrUX und RUM führen.
Zeitspanne
CrUX-Daten basieren auf einem gleitenden Traffic-Fenster von 28 Tagen. Dieser Zeitraum kann nicht geändert werden. Die CrUX-BigQuery-Daten werden jedoch für jeden Monat gespeichert, sodass Sie vorherige Monate sehen können. Die CrUX History API liefert außerdem Verlaufsdaten für einen wöchentlichen Zeitraum. Beide liefern weiterhin Daten basierend auf dem gleitenden 28-Tage-Fenster.
RUM-Daten ermöglichen in der Regel einen viel größeren Detaillierungsgrad, um die Auswirkungen von Änderungen viel schneller erkennen zu können. Wenn Sie kürzere Zeiträume auswählen, können die RUM-Daten jedoch übermäßig durch Schwankungen bei Website-Traffic und Besuchern beeinflusst werden. Wenn Sie RUM-Daten mit CrUX-Daten vergleichen, sollten Sie sich immer die Leistung der letzten 28 Tage ansehen. Wenn Sie sicher sind, dass die Daten ähnlich sind, können Sie sich andere Zeiträume ansehen, um die RUM-Daten aufzuschlüsseln.
Aggregation von Statistiken
Die Messwerte zur Nutzererfahrung in Chrome werden im 75. Perzentil gemessen, also am Wert, den 75% der Seitenaufrufe erzielt haben. Es wird extreme Felddaten geben und die schlimmsten 25% der Nutzer werden beseitigt. Dadurch soll ein Wert geschaffen werden, den die Mehrheit der Besucher nach vernünftigem Ermessen erreichen kann.
RUM-Produkte bieten oft mehr Optionen zum Aggregieren der Messwerte, einschließlich des 75. Perzentils, des Medianwerts und anderer Perzentile. Wenn Sie RUM-Werte mit CrUX-Daten vergleichen, müssen Sie darauf achten, die Daten des 75. Perzentils für einen vergleichbaren Vergleich heranzuziehen.
Die Histogrammdaten in CrUX enthalten alle verfügbaren Daten – nicht nur das 75. Perzentil – und zeigen die Anzahl der Seitenaufrufe in jeder Bewertung an. Die Gesamtpunktzahl basiert jedoch auf dem 75. Perzentil. Diese CrUX-Daten werden in Tools wie PageSpeed Insights angezeigt:
![PageSpeed Insights-Screenshot mit Histogrammen der Seitenladevorgänge für LCP-Bewertungen](https://web.developers.google.cn/static/articles/crux-and-rum-differences/image/pagespeed-insights-screen-b135a0cfa5e39.png?authuser=6&hl=de)
Unterschiede bei Messwerten
Es gibt viele Messwerte, mit denen die Leistung im Web gemessen wird. Wenn Sie also zwei verschiedene Datensätze vergleichen, ist es wichtig zu verstehen, welche Messwerte gemessen und wie diese verwendet werden.
Gemessene Messwerte
CrUX-Daten sind das offizielle Dataset der Core Web Vitals-Initiative. Sie messen hauptsächlich diese Messwerte (LCP, CLS und INP), wobei einige zusätzliche Messwerte ergänzt werden.
RUM-Tools enthalten in der Regel diese Core Web Vitals, häufig aber auch viele andere Messwerte. Einige RUM-Anbieter messen die Nutzererfahrung auch anhand ihrer eigenen Kombination all dieser Messwerte, z. B. um einen „Zufriedenheitsindex“ zu erstellen. oder dergleichen sein. Achten Sie beim Vergleich von RUM-Daten mit CrUX-Daten darauf, dass sie auf ähnliche Weise verglichen werden.
Bei Tools, mit denen geprüft wird, ob eine Seite erfolgreich oder nicht bestanden wurde, sollte sie als bestanden oder nicht bestanden werden, wenn sie im 75. Perzentil die empfohlenen Ziele für alle Core Web Vitals erfüllt. Wenn INP für Seiten ohne Interaktionen nicht vorhanden ist, müssen nur LCP und CLS bestanden werden.
Messwertunterschiede in verschiedenen Browsern
CrUX-Daten werden nur in Chrome-Browsern gemessen. In den Web Vitals-Änderungsprotokollen können Sie nachlesen, wie sich diese mit den einzelnen Chrome-Versionen ändern.
RUM-Lösungen können jedoch Daten von einer größeren Vielfalt von Browsern abrufen. Chromium-basierte Browser (Edge, Opera usw.) ähneln Chrome wahrscheinlich, sofern Chrome keine neuen Änderungen implementiert (siehe Änderungsprotokoll).
Bei anderen Browsern als Chromium sind die Unterschiede deutlicher. First Contentful Paint (FCP) beispielsweise ist in Safari und Firefox verfügbar, wird aber anders gemessen. Dies kann zu erheblichen Abweichungen bei den angegebenen Zeiten führen. Wenn Sie RUM mit CrUX vergleichen möchten, sollten Sie wie bereits erwähnt nach Chrome-Nutzern filtern, um einen vergleichbaren Vergleich zu ermöglichen.
Messwert-Timing
Die Core Web Vitals-Messwerte werden von Webbrowser-APIs bereitgestellt. Das bedeutet jedoch nicht, dass bei den damit gemeldeten Werten keine Unterschiede auftreten können. Der genaue Zeitpunkt, an dem der Messwert erfasst wird – beim Seitenaufbau oder während des gesamten Lebenszyklus der Seite – kann zu Abweichungen führen. RUM-Tools messen Messwerte möglicherweise nicht immer auf dieselbe Weise – selbst wenn sie dieselben Namen verwenden – und dieselben Browser-APIs, um die Daten abzurufen, was verwirrend sein kann.
Der Largest Contentful Paint (LCP) ist ein Messwert für den Seitenaufbau. Eine Reihe von LCP-Elementen kann von der Web API gemeldet werden, wenn größere Elemente später nach dem anfänglichen Rendern geladen werden. Das letzte LCP-Element ist, wenn die Seite fertig geladen ist oder der Nutzer mit der Seite interagiert. Daher können Unterschiede auftreten, wenn das LCP-Element vor diesen beiden Ereignissen gemeldet wird.
Außerdem kann das LCP-Element bei Felddaten je nachdem, wie die Seite geladen wird, unterschiedlich sein. Bei einem standardmäßigen Seitenaufbau, bei dem der obere Teil des Seiteninhalts zu sehen ist, hängt das LCP-Element in erster Linie von der Bildschirmgröße ab. Wird die Seite jedoch mit einem Ankerlink weiter unten im Dokument oder in ähnlicher Weise mit einem Deep-Link zu einer Single-Page-Anwendung (SPA) geöffnet (mehr dazu später), kann das LCP-Element anders sein.
Gehen Sie nicht davon aus, dass die in CrUX oder RUM angegebenen LCP-Zeitangaben auf demselben Element wie die Lab-Tools basieren. Im Bericht zur Nutzererfahrung in Chrome erhalten Sie den gesamten LCP-Wert pro Seite oder Ursprung. In RUM kann dieser Wert jedoch weiter segmentiert werden, um einzelne Sitzungen mit LCP-Problemen zu identifizieren.
Cumulative Layout Shift (CLS) wird über die gesamte Lebensdauer der Seite hinweg gemessen. Daher ist der CLS beim anfänglichen Seitenaufbau möglicherweise nicht repräsentativ für Seiten, die später größere Verschiebungen verursachen, nachdem die Seite geladen wurde und der Nutzer mit ihr interagiert hat. Wenn der CLS-Wert wie bei vielen RUM-Produkten erst nach dem Seitenaufbau erfasst wird, führt dies zu einem anderen Ergebnis, als wenn der CLS-Wert nach dem Seitenaufbau erfasst wird.
Für den Reaktionsgrad Interaction to Next Paint (INP) muss eine Eingabe gemessen werden. Dabei werden alle Klicks, Tippen und Tastaturinteraktionen während der gesamten Lebensdauer der Seite ähnlich wie beim CLS erfasst. Der gemeldete INP-Wert kann also sehr unterschiedlich ausfallen, wenn er nach mehreren Interaktionen auf der Seite erfasst wird.
Für CrUX wird die Core Web Vitals-Dokumentation eingehalten. Diese werden über die gesamte Lebensdauer der Seite gemessen. Viele RUM-Anbieter messen diese Messwerte aus verschiedenen Gründen entweder nach dem Seitenaufbau oder zu einem anderen Zeitpunkt, z. B. wenn ein wichtiger Call-to-Action angeklickt wird.
Wenn Sie unerklärliche Abweichungen zwischen den beiden Datenquellen feststellen, ist es wichtig, von Ihrem RUM-Anbieter zu verstehen, wann Core Web Vitals gemessen wird.
Single-Page-Anwendungen
Bei Single-Page-Anwendungen (SPA) wird der Inhalt der aktuellen Seite aktualisiert, statt Seitennavigation auf Browserebene. Das bedeutet, dass der Browser diese nicht als Seitennavigation erkennt, obwohl sie den Nutzern als solche erlebt werden. Die Core Web Vitals APIs, die über den Browser bereitgestellt werden, berücksichtigen diese nicht. Daher werden diese Seitennavigationen von CrUX nicht unterstützt. Wir arbeiten derzeit an der Lösung dieses Problems. Weitere Informationen finden Sie im Beitrag Experimentieren mit dem Messen von weicher Navigation.
Einige RUM-Anbieter versuchen, „weiche Navigationen“ zu erkennen. in SPAs, aber wenn sie Core Web Vitals-Messwerte auch diesen „weichen Navigationen“ zuordnen Dies führt zu Unterschieden bei CrUX, da die zugrunde liegenden APIs dies bei vielen Messwerten nicht unterstützen.
Unterschiede zwischen CrUX und Web API
Neben den Unterschieden, welche Seitenaufrufe und was gemessen wird, gibt es einige andere, kompliziertere Szenarien, die zu Abweichungen bei CrUX- und RUM-Daten führen können. Einige davon sind auf Einschränkungen der Web-APIs zurückzuführen, die zum Messen der Messwerte verwendet werden. In anderen Fällen müssen die von der API zurückgegebenen Ergebnisse für bestimmte Szenarien anders behandelt werden. In der Core Web Vitals-Dokumentation werden diese Unterschiede für LCP und CLS aufgeführt. Die Hauptunterschiede sind jedoch auch in den folgenden Abschnitten aufgeführt.
Back-Forward-Cache
Für CrUX werden Back-Forward-Cache- oder bfcache-Wiederherstellungen als Seitennavigationen betrachtet, obwohl sie nicht zu einem herkömmlichen Seitenaufbau führen. Da die Web-APIs dies nicht als Seitenaufbau behandeln, müssen RUM-Lösungen zusätzliche Schritte ausführen, damit diese Seiten gezählt werden, wenn sie mit CrUX übereinstimmen. Dabei handelt es sich um deutlich schnellere Seitenladevorgänge, die zu einer insgesamt besseren Leistung in Berichten für eine Website führen können. Wenn Sie sie nicht einschließen, kann dies zu einer schlechteren Gesamtleistung der Seite führen. Sehen Sie in Ihrer RUM-Lösung nach, ob Seiten wiederhergestellt werden, die in bfcache wiederhergestellt wurden.
iFrames
Aus Sicherheits- und Datenschutzgründen haben übergeordnete Seiten keinen Zugriff auf Inhalte in iFrames, auch nicht auf iFrames mit demselben Ursprung. Das bedeutet, dass die Leistungsmesswerte für Inhalte in diesen Inhalten nur vom iFrame selbst und nicht über die Web-APIs auf der Seite mit dem Frame gemessen werden können. Wenn der iFrame-Inhalt das LCP-Element oder Inhalte enthält, die sich auf den CLS- oder INP-Wert des Nutzers auswirken, stehen RUM-Lösungen (einschließlich der Google Webvitals-JavaScript-Bibliothek) nicht zur Verfügung.
Da CrUX jedoch vom Chrome-Browser selbst und nicht vom JavaScript-Code auf der Seite gemessen wird, gelten diese Einschränkungen nicht. Daher werden bei Berichten zu Core Web Vitals auch Messwerte innerhalb von iFrames gemessen. Dies spiegelt die Nutzererfahrung besser wider, kann aber ein weiterer Grund für Unterschiede bei Websites sein, auf denen iFrames verwendet werden.
Ein konkretes Beispiel dafür, wie dies zu Unterschieden zwischen LCP-Daten in CrUX und RUM führen kann, ist <video>
. Der erste dargestellte Frame eines automatisch wiedergegebenen <video>
-Elements kann als LCP-Kandidat gezählt werden. Bei Einbettungen für beliebte Videostreamingdienste können diese Elemente jedoch in einem <iframe>
platziert werden. Das kann in CrUX berücksichtigt werden, da auf <iframe>
-Inhalte zugegriffen werden kann, in RUM-Lösungen jedoch nicht.
Ursprungsübergreifende Ressourcen
LCP-Medien, die von anderen Domains bereitgestellt werden, geben in der PerformanceObserver API keine Renderingzeit an, es sei denn, der Timing-Allow-Origin-Header (TAO) wird bereitgestellt. Dies liegt an Browser-Sicherheitseinschränkungen, um Timing-Angriffe zu reduzieren. Dies berücksichtigt die Ladezeit der Ressource, kann sich jedoch stark von der tatsächlichen Erstellung des Inhalts unterscheiden.
Dies kann dazu führen, dass der LCP von Web-APIs früher als FCP gemeldet wird. Das kann scheinbar unmöglich erscheinen. Das ist nicht der Fall, sondern erscheint aufgrund dieser Sicherheitsbeschränkung nur so.
Auch hier werden die Daten zur Renderingzeit für Core Web Vitals erfasst. Wir empfehlen Websites, ursprungsübergreifende Inhalte, die sich auf die Core Web Vitals-Messwerte auswirken, einzuschränken, und den TAO nach Möglichkeit zu aktivieren, wenn dies genauer gemessen werden soll. Andere ursprungsübergreifende Ressourcen können ähnlichen Einschränkungen unterliegen.
Tabs im Hintergrund
Wenn eine Seite nicht in einem Tab im Hintergrund geöffnet wird, werden trotzdem Messwerte über Web APIs ausgegeben. Sie werden jedoch nicht von Chrome UX-Berichten erfasst, da sie Zeitangaben enthalten, die nicht der Nutzererfahrung entsprechen. RUM-Lösungen sollten diese auch ignorieren oder zumindest erklären, wie diese Seitenaufrufe behandelt werden.
Was können wir also tun?
Wir haben gezeigt, dass es Unterschiede zwischen den Daten zur Nutzererfahrung in Chrome und den RUM-Daten gibt. Diese können auf unterschiedliche Methodiken zurückzuführen sein oder darauf, welche Nutzer und Seitenaufrufe ein- oder ausgeschlossen werden. Im Idealfall sind beide Datensätze immer noch repräsentativ für die Leistung Ihrer Website, um nützlich zu sein. Die angegebenen Gründe sollten jedoch umreißen, warum es sehr unwahrscheinlich ist, dass beide Datensätze dieselben Zahlen erhalten.
Bei geringfügigen Unterschieden (z.B.bei einem LCP von 2,0 Sekunden im Vergleich zu 2,2 Sekunden) sind beide Datasets nützlich und können in der Regel als ungefähr synchron angesehen werden.
Wenn ausgeprägte Unterschiede die Genauigkeit der Daten infrage stellen, sollten Sie versuchen, diese Unterschiede zu verstehen. Können die RUM-Daten gefiltert werden, um sie besser an CrUX-Daten anzupassen (nur Chrome-Nutzer, Computer oder Mobilgeräte mit dem 75. Perzentil über 28 Tage), um diese Unterschiede zu verringern?
Wenn ja, und Sie die Daten besser aufeinander abstimmen können, sollten Sie trotzdem fragen, warum Sie diese Unterschiede in den Gesamtdaten sehen und was das bedeutet. Verzerren Nutzer, die Chrome nicht verwenden, Ihre Messwerte positiv oder negativ? Gibt es so einen besseren Überblick darüber, wo Leistungsprobleme auftreten, die du priorisieren solltest?
Wenn Ihre Nicht-Chrome-Nutzer unterschiedliche Ergebnisse erhalten, können Sie diese wertvollen Erkenntnisse nutzen, die RUM Ihnen für die Optimierung zur Verfügung gestellt hat. Beispielsweise sind bestimmte APIs in bestimmten Browsern nicht verfügbar. Sie können jedoch auch Alternativen für nicht unterstützte Browser in Betracht ziehen, um die Nutzerfreundlichkeit zu verbessern. Oder Sie können Nutzern mit eingeschränkten Geräten oder Netzwerken eine andere, aber leistungsstärkere Funktion bieten. CrUX ist auf Chrome-Daten beschränkt, Sie sollten aber die um Verbesserungen zu priorisieren. RUM-Daten können diese Lücke füllen.
Sobald Sie die Gründe für die Unterschiede kennen, können beide Tools sehr nützlich sein, um die Nutzererfahrung auf Ihrer Website zu verstehen und diese zu verbessern, auch wenn die Zahlen nicht identisch sind. Verwenden Sie Ihre RUM-Daten als Ergänzung zu CrUX-Daten und ermöglichen Sie einen umfassenden Überblick über die Informationen, die Sie von CrUX erhalten. Segmentieren Sie dazu Ihren Traffic, um zu erkennen, ob es sich um bestimmte Bereiche Ihrer Website oder Nutzergruppe handelt, die Aufmerksamkeit erfordern.
Wenn Sie sich die Trends ansehen, um festzustellen, ob Sie die erwarteten positiven Auswirkungen haben, ist es oft wichtiger, als jede Zahl genau zwischen den beiden Datenquellen zu stimmen. Wie bereits erwähnt, können Sie sich in RUM verschiedene Zeiträume ansehen, um einen Vorabblick auf Ihre CrUX-Werte für die letzten 28 Tage zu erhalten. Wenn Sie jedoch zu kurze Zeiträume betrachten, kann dies zu ungenauen Daten führen, weshalb für CrUX 28 Tage erforderlich sind.
Oft gibt es kein „richtiges“ oder „falsch“ diese unterschiedlichen Messwerte beantworten. Sie sind lediglich ein unterschiedlicher Blickwinkel auf Ihre Nutzer und die Art und Weise, wie sie Ihre Website erleben. Wenn Sie verstehen, warum diese Unterschiede auftreten und was diese als Entscheidungshilfe für Ihre Website-Besucher dienen können, ist dies für die Website-Besucher wichtiger denn je.
Danksagungen
Miniaturansicht von Steven Lelham auf Unsplash