Hier erfahren Sie, warum bei Tools, mit denen Core Web Vitals-Messwerte überwacht werden, unterschiedliche Zahlen gemeldet werden können und wie Sie diese Unterschiede interpretieren.
Google bietet verschiedene Tools, mit denen Websiteinhaber ihre Core Web Vitals-Werte beobachten können. Diese Tools lassen sich in zwei Hauptkategorien unterteilen:
- Tools zur Berichterstellung für Lab-Daten, also Daten, die in einer kontrollierten Umgebung mit vordefinierten Geräte- und Netzwerkeinstellungen erfasst werden.
- Tools zur Erstellung von Berichten zu Felddaten – Daten von echten Nutzern, die Ihre Website besuchen.
Das Problem ist, dass sich die von Labortools gemeldeten Daten manchmal stark von den Daten unterscheiden, die von Feldtools gemeldet werden. Ihre Labdaten deuten darauf hin, dass Ihre Website eine gute Leistung erzielt, aber Ihre Felddaten deuten darauf hin, dass sie verbessert werden muss. Alternativ können in Ihren Felddaten angegeben sein, dass alle Ihre Seiten in Ordnung sind, Ihre Labdaten jedoch eine sehr niedrige Punktzahl melden.
Das folgende echte Beispiel eines PageSpeed Insights-Berichts von web.dev zeigt, dass die Lab- und Felddaten in einigen Fällen bei allen Core Web Vitals-Messwerten unterschiedlich sein können:
Unterschiede zwischen den Tools können für Entwickler verständlichermaßen Verwirrung führen. In diesem Beitrag werden die Hauptgründe dafür erläutert. Dabei werden konkrete Beispiele zu jedem der Core Web Vitals-Messwerte genannt. Außerdem wird erläutert, was zu tun ist, wenn Sie Unterschiede auf Ihren Seiten feststellen.
Labdaten und Felddaten im Vergleich
Um zu verstehen, warum Lab- und Field Tools unterschiedliche Werte melden können – selbst für genau dieselbe Webseite – müssen Sie den Unterschied zwischen Lab- und Felddaten verstehen.
Labdaten
Zum Ermitteln der Labdaten wird eine Webseite in einer kontrollierten Umgebung mit vordefinierten Netzwerk- und Gerätebedingungen geladen. Diese Bedingungen werden als Lab-Umgebung bezeichnet, manchmal auch als synthetische Umgebung bezeichnet.
In Chrome-Tools, die Labdaten melden, wird in der Regel Lighthouse ausgeführt.
Der Zweck eines Labortests besteht darin, so viele Faktoren wie möglich zu kontrollieren, damit die Ergebnisse (soweit möglich) einheitlich und reproduzierbar sind.
Felddaten
Felddaten werden durch Überwachen aller Nutzer, die eine Seite besuchen, und durch Messen einer bestimmten Reihe von Leistungsmesswerten für jede individuelle Erfahrung dieser Nutzer ermittelt. Da Felddaten auf echten Nutzerbesuchen basieren, spiegeln sie die tatsächlichen Geräte, Netzwerkbedingungen und geografischen Standorte Ihrer Nutzer wider.
Felddaten werden auch als RUM-Daten (Real User Monitoring) bezeichnet. Die beiden Begriffe sind austauschbar.
Chrome-Tools, die Felddaten ausgeben, beziehen diese Daten in der Regel aus dem Bericht zur Nutzererfahrung in Chrome (Chrome User Experience, CrUX). Außerdem ist es üblich und auch empfehlenswert, Felddaten selbst zu erfassen, da sich so mehr umsetzbare Informationen als mit CrUX allein erheben lassen.
Das Wichtigste bei Felddaten ist, dass es sich nicht nur um eine Zahl, sondern um eine Verteilung von Zahlen handelt. Das heißt, dass sie bei einigen Besuchern Ihrer Website sehr schnell geladen wird, während sie bei anderen sehr langsam geladen wird. Die Felddaten für Ihre Website enthalten alle Leistungsdaten, die von Ihren Nutzern erfasst werden.
Beispielsweise zeigen CrUX-Berichte die Verteilung der Leistungsmesswerte echter Chrome-Nutzer über einen Zeitraum von 28 Tagen. Wenn Sie sich fast alle Berichte zur Nutzererfahrung in Chrome ansehen, werden Sie feststellen, dass einige Nutzer, die eine Website besuchen, eine sehr gute und andere eher schlechte Erfahrungen machen.
Wenn ein Tool eine einzelne Zahl für einen bestimmten Messwert meldet, stellt es in der Regel einen bestimmten Punkt in der Verteilung dar. Tools, die Punktzahlen für das Core Web Vitals-Feld melden, tun dies auf Basis des 75. Perzentils.
Wenn Sie sich den LCP-Wert in den Felddaten im Screenshot oben ansehen, erkennen Sie eine Verteilung, bei der Folgendes gilt:
- Bei 88% der Besuche betrug der LCP 2,5 Sekunden oder weniger (gut).
- Bei 8% der Besuche wurde ein LCP zwischen 2,5 und 4 Sekunden festgestellt (Optimierung erforderlich).
- Bei 4% der Besuche wurde ein LCP von mehr als 4 Sekunden (schlecht) erlebt.
Auf dem 75.Perzentil betrug der LCP 1, 8 Sekunden:
Labdaten von derselben Seite zeigen einen LCP-Wert von 3,0 Sekunden. Obwohl dieser Wert größer als die 1,8 Sekunden ist, die in den Felddaten angezeigt werden, ist er dennoch ein gültiger LCP-Wert für diese Seite – er ist einer von vielen Werten, die die vollständige Verteilung der Ladevorgänge ausmachen.
Warum sich Lab- und Felddaten unterscheiden
Wie im obigen Abschnitt erläutert, messen Lab- und Felddaten sehr unterschiedliche Dinge.
Felddaten umfassen eine Vielzahl von Netzwerk- und Gerätebedingungen sowie eine Vielzahl verschiedener Arten von Nutzerverhalten. Dazu gehören auch andere Faktoren, die sich auf die Nutzerfreundlichkeit auswirken, z. B. Browseroptimierungen wie der Back-Forward-Cache (bfcache) oder Plattformoptimierungen wie der AMP-Cache.
Im Gegensatz dazu wird die Anzahl der Variablen in Labdaten absichtlich begrenzt. Ein Lab-Test besteht aus:
- Ein einzelnes Gerät...
- mit einem einzelnen Netzwerk verbunden...
- die von einem einzigen geografischen Standort aus ausgeführt werden.
Die Angaben eines bestimmten Labortests können das 75. Perzentil der Felddaten für eine bestimmte Seite oder Website genau wiedergeben.
Die kontrollierte Umgebung des Labs ist nützlich, wenn Sie Probleme beheben oder Funktionen vor der Bereitstellung für die Produktion testen möchten. Wenn Sie jedoch diese Faktoren kontrollieren, stellen Sie nicht die Abweichung dar, die in der realen Welt bei allen Netzwerktypen, Gerätefunktionen oder geografischen Standorten auftritt. Außerdem erfassen Sie in der Regel nicht, wie sich das tatsächliche Nutzerverhalten auf die Leistung auswirkt, z. B. Scrollen, Auswählen von Text oder Antippen von Elementen auf der Seite.
Neben der möglichen Trennung zwischen Laborbedingungen und den Bedingungen der meisten realen Nutzer gibt es auch einige kleinere Unterschiede, die Sie verstehen müssen, um Ihre Labor- und Felddaten sowie etwaige Unterschiede sinnvoll zu nutzen.
In den nächsten Abschnitten werden die häufigsten Gründe für Unterschiede zwischen Lab- und Felddaten für jeden der Core Web Vitals-Messwerte hervorgehoben:
LCP
Verschiedene LCP-Elemente
Das in einem Labortest identifizierte LCP-Element ist möglicherweise nicht dasselbe LCP-Element, das Nutzer beim Besuch Ihrer Seite sehen.
Wenn Sie einen Lighthouse-Bericht für eine bestimmte Seite erstellen, wird jedes Mal dasselbe LCP-Element zurückgegeben. Wenn Sie sich jedoch Felddaten für dieselbe Seite ansehen, finden Sie normalerweise eine Vielzahl verschiedener LCP-Elemente, die von einer Reihe von Gegebenheiten abhängig vom jeweiligen Seitenbesuch abhängen.
Beispielsweise können die folgenden Faktoren dazu beitragen, dass ein anderes LCP-Element für dieselbe Seite ermittelt wird:
- Unterschiedliche Gerätebildschirmgrößen führen dazu, dass im Darstellungsbereich unterschiedliche Elemente sichtbar sind.
- Wenn der Nutzer angemeldet ist oder personalisierte Inhalte auf irgendeine Weise angezeigt werden, kann das LCP-Element von Nutzer zu Nutzer sehr unterschiedlich sein.
- Ähnlich wie im vorherigen Schritt kann ein A/B-Test auf einer Seite dazu führen, dass sehr unterschiedliche Elemente angezeigt werden.
- Der auf dem System des Nutzers installierte Satz von Schriftarten kann sich auf die Textgröße auf der Seite auswirken (und somit darauf, welches Element das LCP-Element ist).
- Lab-Tests werden normalerweise auf der "Basis-URL" einer Seite ausgeführt, ohne dass Suchparameter oder Hash-Fragmente hinzugefügt werden. In der Praxis verwenden Nutzer jedoch häufig URLs, die eine Fragment-ID oder ein Textfragment enthalten. Daher kann sich das LCP-Element tatsächlich in der Mitte oder unten auf der Seite befinden (und nicht „above the fold“).
Der LCP-Wert im Feld wird als 75. Perzentil aller Nutzerbesuche auf einer Seite berechnet. Wenn ein großer Prozentsatz dieser Nutzer ein LCP-Element hatte, das sehr schnell geladen wurde – z. B. ein Textabsatz mit einer Systemschrift –, wirkt sich dies möglicherweise nicht auf die Bewertung der Seite aus, wenn es bei weniger als 25 % der Besucher ein großes, langsam ladendes Bild als LCP-Element gibt.
Alternativ könnte das Gegenteil der Fall sein. Bei einem Labortest kann ein Textblock als LCP-Element identifiziert werden, weil er ein Moto G4-Smartphone mit einem relativ kleinen Darstellungsbereich emuliert und das Hero-Image der Seite zuerst außerhalb des Bildschirms gerendert wird. Ihre Felddaten enthalten jedoch möglicherweise hauptsächlich Pixel XL-Nutzer mit größeren Bildschirmen. Für sie ist also das langsam ladende Hero-Image ihr LCP-Element.
Auswirkungen des Cache-Status auf den LCP
Bei Lab-Tests wird eine Seite mit einem kalten Cache in der Regel geladen, aber wenn echte Nutzer diese Seite besuchen, sind einige ihrer Ressourcen möglicherweise bereits im Cache gespeichert.
Wenn ein Nutzer eine Seite zum ersten Mal lädt, wird sie unter Umständen nur langsam geladen. Wenn für die Seite aber ein richtiges Caching konfiguriert ist, wird die Seite möglicherweise sofort geladen, wenn der Nutzer das nächste Mal zurückkehrt.
Einige Lab-Tools unterstützen mehrere Ausführungen derselben Seite (um die Nutzererfahrung für wiederkehrende Besucher zu simulieren). Mit einem Lab-Tool lässt sich jedoch nicht ermitteln, wie viel Prozent der Besuche in der realen Welt von neuen und wiederkehrenden Nutzern stammen.
Bei Websites mit optimierten Cache-Konfigurationen und vielen wiederkehrenden Besuchern kann es vorkommen, dass ihr LCP in der Praxis viel schneller ist, als die Labdaten ausweisen.
AMP- oder Signed Exchange-Optimierungen
Websites, die mit AMP erstellt wurden oder auf denen Signed Exchanges (SXG) verwendet werden, können von Inhaltsaggregatoren wie der Google Suche vorab geladen werden. Dies kann zu einer deutlich besseren Ladeleistung für Nutzer führen, die Ihre Seiten über diese Plattformen besuchen.
Zusätzlich zum ursprungsübergreifenden Vorabladen können Websites selbst Inhalte für nachfolgende Seiten der Website vorab laden, wodurch auch der LCP-Wert für diese Seiten verbessert werden könnte.
Lab-Tools simulieren die durch diese Optimierungen erzielten Vorteile nicht. Selbst wenn sie dies taten, könnten sie nicht wissen, wie viel Prozent des Traffics von Plattformen wie der Google Suche im Vergleich zu anderen Quellen stammt.
Auswirkungen von bfcache auf den LCP
Wenn Seiten aus dem bfcache wiederhergestellt werden, erfolgt der Ladevorgang nahezu sofort und diese Tests sind in Ihren Felddaten enthalten.
Bei Labortests wird „bfcache“ nicht berücksichtigt. Wenn Ihre Seiten also bfcache-freundlich sind, werden die LCP-Werte wahrscheinlich schneller erfasst.
Auswirkungen von Nutzerinteraktionen auf den LCP
Der LCP ermittelt die Renderingzeit des größten Bilds oder Textblocks im Darstellungsbereich. Dieses größte Element kann sich jedoch ändern, wenn die Seite geladen wird oder wenn neue Inhalte dynamisch zum Darstellungsbereich hinzugefügt werden.
Im Lab wartet der Browser, bis die Seite vollständig geladen ist, bevor er ermittelt, was das LCP-Element war. In diesem Fall unterbricht der Browser die Überwachung auf größere Elemente, wenn der Nutzer scrollt oder mit der Seite interagiert.
Das macht Sinn (und ist notwendig), da Nutzer in der Regel warten, bis sie mit einer Seite interagieren, bis sie „erscheint“ geladen ist. Genau das soll mit dem LCP-Messwert ermittelt werden. Außerdem macht es keinen Sinn, Elemente zu berücksichtigen, die dem Darstellungsbereich nach einer Interaktion des Nutzers hinzugefügt wurden, weil diese Elemente möglicherweise nur aufgrund von Aktionen des Nutzers geladen wurden.
Dies hat jedoch zur Folge, dass Felddaten für eine Seite je nach Verhalten der Nutzer auf der Seite unter Umständen schneller die LCP-Zeiten erfassen.
FID
FID erfordert eine echte Nutzerinteraktion
Der FID-Messwert gibt an, wie schnell eine Seite auf Nutzerinteraktionen reagiert, zu dem Zeitpunkt, zu dem der Nutzer tatsächlich mit ihr interagiert hat.
Der zweite Teil des Satzes ist wichtig, da bei Labortests, auch bei solchen, die Skriptnutzerverhalten unterstützen, nicht genau vorhersagen kann, wann Nutzer mit einer Seite interagieren und somit die FID nicht genau messen können.
TBT berücksichtigt nicht das Nutzerverhalten
Der Lab-Messwert Total Blocking Time (TBT) ist für die Diagnose von FID-Problemen gedacht, da er quantifiziert, wie viel der Hauptthread beim Seitenaufbau blockiert ist.
Die Idee dahinter ist, dass Seiten mit vielen synchronen JavaScript- oder anderen intensiven Renderingaufgaben mit höherer Wahrscheinlichkeit einen blockierten Hauptthread haben, wenn der Nutzer zum ersten Mal interagiert. Wenn Nutzer jedoch mit der Interaktion mit der Seite warten, bis das JavaScript ausgeführt wurde, ist die FID möglicherweise sehr niedrig.
Wann Nutzer mit einer Seite interagieren, hängt vor allem davon ab, ob sie interaktiv aussieht oder nicht. Dies kann mit TBT nicht gemessen werden.
TBT berücksichtigt keine Tippverzögerung
Wenn eine Website nicht für Mobilgeräte optimiert ist, wird in Browsern nach jedem Tippen vor dem Ausführen von Event-Handlern eine Verzögerung von 300 ms hinzugefügt. Das liegt daran, dass sie erst ermitteln müssen, ob der Nutzer durch Doppeltippen zum Zoomen Maus- oder Klickereignisse auslösen kann.
Diese Verzögerung wird auf die FID einer Seite angerechnet, da sie zur tatsächlichen Eingabelatenz der Nutzer beiträgt. Da diese Verzögerung jedoch technisch gesehen keine lange Aufgabe ist, wirkt sie sich nicht auf die TBT einer Seite aus. Das bedeutet, dass eine Seite trotz sehr guter TBT-Werte einen schlechten FID-Wert haben kann.
Auswirkungen des Cache-Status und des bfcache auf FID
So wie ein ordnungsgemäßes Caching den LCP vor Ort und auch FID verbessern kann.
In der Praxis kann es vorkommen, dass ein Nutzer das JavaScript für eine Website bereits in seinem Cache gespeichert hat, sodass die Verarbeitung weniger Zeit in Anspruch nehmen und zu geringeren Verzögerungen führen könnte.
Dasselbe gilt für aus dem bfcache wiederhergestellte Seiten. In diesen Fällen wird das JavaScript aus dem Speicher wiederhergestellt, sodass nur wenig oder gar keine Verarbeitungszeit zur Verfügung steht.
CLS
Auswirkungen von Nutzerinteraktionen auf CLS
Bei der im Lab gemessenen CLS werden nur Layoutverschiebungen berücksichtigt, die „above the fold“ und während des Ladens auftreten. Dies ist jedoch nur ein Teil dessen, was von CLS tatsächlich gemessen wird.
Dabei berücksichtigt CLS alle unerwarteten Layoutverschiebungen, die während der gesamten Lebensdauer der Seite auftreten. Dazu gehören auch Inhalte, die sich verschieben, wenn der Nutzer scrollt, oder als Reaktion auf langsame Netzwerkanfragen nach der Nutzerinteraktion.
Beispielsweise kommt es häufig für Seiten mit Lazy Loading für Bilder oder iFrames ohne Abmessungen vor. Dies kann zu Layoutverschiebungen führen, wenn ein Nutzer zu diesen Abschnitten der Seite scrollt. Diese Änderungen können jedoch nur auftreten, wenn der Nutzer nach unten scrollt, was bei einem Labortest häufig nicht erfasst wird.
Personalisierter Inhalt
Personalisierte Inhalte wie Anzeigen mit Targeting und A/B-Tests haben Einfluss darauf, welche Elemente auf einer Seite geladen werden. Sie wirkt sich auch darauf aus, wie sie geladen werden, da personalisierte Inhalte oft später geladen und in den Hauptinhalt einer Seite eingefügt werden. Dadurch kommt es zu Layoutverschiebungen.
Im Lab wird eine Seite in der Regel entweder ohne personalisierte Inhalte oder mit Inhalten für einen generischen "Testnutzer" geladen. Dies kann die Verschiebungen auslösen, die echte Nutzer sehen.
Da Felddaten die Erfahrungen aller Nutzer enthalten, hängen die Menge (und der Grad) der Layoutverschiebungen auf einer bestimmten Seite stark davon ab, welche Inhalte geladen werden.
Auswirkungen des Cache-Status und des bfcache auf CLS
Zwei der häufigsten Ursachen für Layoutverschiebungen während des Ladens sind Bilder und iFrames ohne Abmessungen (wie oben erwähnt) sowie langsam ladende Webschriftarten. Beide Probleme wirken sich eher auf die Nutzererfahrung aus, wenn ein Nutzer eine Website zum ersten Mal besucht, wenn der Cache leer ist.
Wenn die Ressourcen einer Seite im Cache gespeichert sind oder die Seite selbst aus dem bfcache wiederhergestellt wird, kann der Browser Bilder und Schriftarten in der Regel sofort rendern, ohne auf den Download warten zu müssen. Dies kann zu niedrigeren CLS-Werten im Feld führen als von einem Lab-Tool ausgegeben.
Was tun, wenn sich die Ergebnisse unterscheiden
Allgemein gilt: Wenn für eine bestimmte Seite sowohl Feld- als auch Labdaten vorhanden sind, sollten Sie Felddaten verwenden, um Ihre Bemühungen zu priorisieren. Felddaten stellen dar, was echte Nutzer erleben. Daher sind sie die genaueste Methode, um wirklich zu verstehen, mit welchen Problemen Ihre Nutzer zu kämpfen haben und was verbessert werden muss.
Wenn Ihre Felddaten jedoch generell gute Werte zeigen, die Labdaten aber auf Verbesserungspotenzial hinweisen, ist es hilfreich zu verstehen, welche weiteren Optimierungen möglich sind.
Mithilfe von Felddaten werden zwar echte Nutzererfahrungen erfasst, sie jedoch nur für Nutzer, die Ihre Website erfolgreich laden können. Labdaten können manchmal dabei helfen, Möglichkeiten zur Erweiterung der Reichweite Ihrer Website zu identifizieren und sie für Nutzer mit langsameren Netzwerken oder weniger leistungsfähigen Geräten zugänglicher zu machen.
Insgesamt sind sowohl Lab- als auch Felddaten wichtige Bestandteile einer effektiven Leistungsmessung. Beide haben ihre Stärken und Einschränkungen, und wenn Sie nur einen verwenden, verpassen Sie möglicherweise die Möglichkeit, die Nutzererfahrung für Ihre Nutzer zu verbessern.