Warum sich Labor- und Felddaten voneinander unterscheiden (und was Sie dagegen tun können)

Hier erfahren Sie, warum Tools, mit denen Core Web Vitals-Messwerte überwacht werden, unter Umständen unterschiedliche Zahlen ausgeben und wie Sie diese Unterschiede interpretieren.

Philip Walton
Philip Walton

Google bietet verschiedene Tools, mit denen Websiteinhaber ihre Core Web Vitals-Werte im Blick behalten können. Diese Tools lassen sich in zwei Hauptkategorien einteilen:

  • Tools, die Berichte zu Labdaten erstellen – Daten, die in einer kontrollierten Umgebung mit vordefinierten Geräte- und Netzwerkeinstellungen erfasst werden.
  • Tools zur Berichterstellung für Felddaten – Daten, die von den tatsächlichen Nutzern erhoben werden, die Ihre Website besuchen.

Das Problem ist, dass sich die von Labortools gemeldeten Daten teilweise stark von den Daten unterscheiden, die von Field Tools gemeldet werden. Ihre Labdaten deuten darauf hin, dass Ihre Website eine gute Leistung erbringt, aber Ihre Felddaten deuten darauf hin, dass sie verbessert werden sollte. Alternativ könnten in Ihren Felddaten alle Seiten in Ordnung sein, Ihre Labdaten weisen jedoch möglicherweise eine sehr niedrige Punktzahl auf.

Das folgende echte Beispiel eines PageSpeed Insights-Berichts von web.dev zeigt, dass Lab- und Felddaten in einigen Fällen bei allen Core Web Vitals-Messwerten unterschiedlich sein können:

Screenshot eines PageSpeed Insights-Berichts mit widersprüchlichen Lab- und Felddaten

Unterschiede zwischen den Tools sind für Entwickler eine nachvollziehbare Ursache für Verwirrung. In diesem Beitrag werden die Hauptgründe dafür erläutert. Außerdem enthält er spezifische Beispiele für die einzelnen Core Web Vitals-Messwerte. Außerdem wird erläutert, was zu tun ist, wenn du Unterschiede auf deinen Seiten feststellst.

Lab- und Felddaten im Vergleich

Um zu verstehen, warum Lab- und Field-Tools unterschiedliche Werte melden können – auch für genau dieselbe Webseite –, müssen Sie den Unterschied zwischen Lab- und Felddaten kennen.

Labdaten

Labdaten werden ermittelt, indem eine Webseite in einer kontrollierten Umgebung mit vordefinierten Netzwerk- und Gerätebedingungen geladen wird. Diese Bedingungen werden als Lab-Umgebung bezeichnet, manchmal auch als synthetische Umgebung bezeichnet.

Chrome-Tools, die Labordaten melden, führen in der Regel Lighthouse aus.

Der Zweck eines Labortests besteht darin, so viele Faktoren wie möglich zu kontrollieren, damit die Ergebnisse (möglichst) konsistent und reproduzierbar sind.

Felddaten

Felddaten werden ermittelt, indem alle Nutzer überwacht werden, die eine Seite besuchen, und eine bestimmte Reihe von Leistungsmesswerten für jede individuelle Erfahrung dieser Nutzer messen. Da Felddaten auf Besuchen von echten Nutzern 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 (CrUX). Es ist auch üblich (und empfohlen), Felddaten selbst zu erfassen, da sie mehr umsetzbare Informationen liefern als die reine Verwendung von CrUX.

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.

In CrUX-Berichten ist beispielsweise die Verteilung der Leistungsmesswerte echter Chrome-Nutzer über einen Zeitraum von 28 Tagen zu sehen. Wenn Sie sich fast alle Berichte zur Nutzererfahrung in Chrome ansehen, werden Sie feststellen, dass einige Nutzer, die eine Website besuchen, möglicherweise eine sehr gute und andere eher schlechte Erfahrungen machen.

Wenn ein Tool eine einzelne Zahl für einen bestimmten Messwert meldet, repräsentiert es in der Regel einen bestimmten Punkt in der Verteilung. Tools, die die Punktzahlen des Core Web Vitals-Felds melden, verwenden hierfür das 75. Perzentil.

Wenn Sie sich den LCP-Wert der Felddaten im Screenshot oben ansehen, sehen Sie eine Verteilung, wobei:

  • Bei 88% der Besuche wurde ein LCP von 2,5 Sekunden oder weniger erfasst (gut).
  • Bei 8% der Besuche wurde ein LCP zwischen 2,5 und 4 Sekunden erfasst (Optimierung erforderlich).
  • Bei 4% der Besuche wurde ein LCP von mehr als 4 Sekunden erfasst (schlecht).

Beim 75.Perzentil betrug der LCP 1, 8 Sekunden:

Verteilung der LCP-Werte vor Ort

Die Lab-Daten derselben Seite haben einen LCP-Wert von 3,0 Sekunden. Dieser Wert ist zwar größer als die 1,8 Sekunden, die in den Felddaten angezeigt werden, ist aber immer noch ein gültiger LCP-Wert für diese Seite – er ist einer von vielen Werten, die die vollständige Verteilung der Ladevorgänge ausmachen.

LCP-Wert im Lab

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 unzählige verschiedene Arten von Nutzerverhalten. Außerdem werden alle anderen Faktoren einbezogen, die sich auf die Nutzererfahrung auswirken, wie Browseroptimierungen wie der Back-Forward-Cache (bfcache) oder Plattformoptimierungen wie der AMP-Cache.

Im Gegensatz dazu wird bei Labdaten absichtlich die Anzahl der beteiligten Variablen begrenzt. Ein Lab-Test besteht aus:

  • Ein einzelnes Gerät...
  • mit einem einzelnen Netzwerk verbunden...
  • nur an einem einzigen geografischen Standort ausgeführt werden.

Die Details eines bestimmten Labortests können das 75. Perzentil der Felddaten für eine bestimmte Seite oder Website korrekt wiedergeben.

Die kontrollierte Umgebung des Labs ist nützlich, wenn Sie Probleme beheben oder Features vor der Bereitstellung für die Produktion testen möchten. Wenn Sie diese Faktoren aber selbst kontrollieren, repräsentieren Sie explizit nicht die Abweichung, die in der realen Welt bei allen Netzwerktypen, Gerätefunktionen oder geografischen Standorten auftritt. Außerdem erfassen Sie in der Regel nicht die Auswirkungen des echten Nutzerverhaltens auf die Leistung, z. B. Scrollen, Auswählen von Text oder Antippen von Elementen auf der Seite.

Neben der möglichen Diskrepanz zwischen den Laborbedingungen und den Bedingungen der meisten realen Nutzer gibt es auch einige kleinere Unterschiede, die Sie kennen sollten, damit Sie Ihre Lab- und Felddaten sowie etwaige Unterschiede möglichst sinnvoll einsetzen können.

In den nächsten Abschnitten werden die häufigsten Gründe für Unterschiede zwischen Lab- und Felddaten bei jedem der Core Web Vitals-Messwerte erläutert:

LCP

Verschiedene LCP-Elemente

Das in einem Labortest identifizierte LCP-Element entspricht möglicherweise nicht dem 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 spezifischen Bedingungen für jeden Seitenbesuch abhängen.

Die folgenden Faktoren können beispielsweise dazu beitragen, dass ein anderes LCP-Element für dieselbe Seite ermittelt wird:

  • Unterschiedliche Bildschirmgröß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 Punkt kann ein A/B-Test auf einer Seite dazu führen, dass sehr unterschiedliche Elemente angezeigt werden.
  • Die auf dem System des Nutzers installierten Schriftarten können die Textgröße auf der Seite beeinflussen (und somit das Element, das 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 das LCP-Element tatsächlich aus der Mitte oder unten auf der Seite stammen und nicht „above the fold“ (ohne Scrollen sichtbar).

Da der LCP im Feld als 75. Perzentil aller Nutzerbesuche einer Seite berechnet wird, hat ein großer Prozentsatz dieser Nutzer ein sehr schnell geladenes LCP-Element – z. B. ein Textabschnitt, der mit einer Systemschrift gerendert wurde –, selbst wenn einige dieser Nutzer ein großes, langsam ladendes Bild als LCP-Element verwenden, wirkt sich dies möglicherweise nicht auf die Bewertung der Seite aus, wenn es bei weniger als 25 % der Fall ist.

Alternativ könnte das Gegenteil der Fall sein. Bei einem Lab-Test könnte ein Textblock als LCP-Element identifiziert werden, da es ein Moto G4-Smartphone mit einem relativ kleinen Darstellungsbereich emuliert und das Hero-Image Ihrer Seite zuerst außerhalb des Bildschirms gerendert wird. Ihre Felddaten umfassen jedoch möglicherweise hauptsächlich Pixel XL-Nutzer mit größeren Bildschirmen. Für sie ist das langsam ladende Hero-Image also ihr LCP-Element.

Auswirkungen des Cache-Status auf den LCP

Bei Labortests wird eine Seite mit einem kalten Cache in der Regel geladen, aber wenn echte Nutzer diese Seite besuchen, haben sie möglicherweise bereits einige der Ressourcen im Cache gespeichert.

Wenn ein Nutzer eine Seite zum ersten Mal lädt, wird sie möglicherweise nur langsam geladen. Wenn für die Seite jedoch das richtige 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 kann jedoch nicht ermittelt werden, wie viel Prozent der tatsächlichen Besuche von neuen und wiederkehrenden Nutzern stammen.

Bei Websites mit optimierten Cache-Konfigurationen und vielen wiederkehrenden Besuchern kann es sein, dass ihr LCP in der Praxis viel schneller ist, als es aus den Labdaten hervorgeht.

AMP- oder Signed Exchange-Optimierungen

Websites, die mit AMP erstellt wurden oder Signed Exchanges (SXG) verwenden, 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 Inhalte für nachfolgende Seiten ihrer Website vorab laden, wodurch auch der LCP-Wert für diese Seiten verbessert werden könnte.

Lab-Tools simulieren nicht die durch diese Optimierungen erzielten Vorteile. Selbst wenn sie dies getan haben, könnten sie nicht wissen, wie viel Prozent des Traffics von Plattformen wie der Google Suche im Vergleich zu anderen Quellen stammen.

Auswirkungen von bfcache auf LCP

Wenn Seiten aus dem bfcache wiederhergestellt werden, erfolgt der Ladevorgang nahezu sofort und diese Vorgänge sind in Ihren Felddaten enthalten.

Bei Labortests wird „bfcache“ nicht berücksichtigt. Wenn Ihre Seiten also bfcache-freundlich sind, werden wahrscheinlich schnellere LCP-Werte gemeldet.

Auswirkungen von Nutzerinteraktionen auf den LCP

Der LCP ermittelt die Renderingzeit des größten Bild- oder Textblocks im Darstellungsbereich. Das 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, und ermittelt dann das LCP-Element. In diesem Fall beendet der Browser die Überwachung für größere Elemente, nachdem der Nutzer auf der Seite scrollt oder mit ihr interagiert.

Das ist sinnvoll (und ist erforderlich), da Nutzer in der Regel mit der Interaktion mit einer Seite warten, bis sie „erscheint“ geladen wird. Das ist genau das, was der LCP-Messwert erkennen soll. Außerdem ist es nicht sinnvoll, Elemente zu berücksichtigen, die dem Darstellungsbereich hinzugefügt werden, nachdem ein Nutzer interagiert hat, da diese Elemente möglicherweise nur aufgrund einer Aktivität des Nutzers geladen wurden.

Dies hat jedoch zur Folge, dass Felddaten für eine Seite je nach Verhalten der Nutzer auf dieser Seite möglicherweise schnellere LCP-Zeiten melden.

FID

FID erfordert Interaktion mit echten Nutzern

Der FID-Messwert misst, wie schnell eine Seite auf Nutzerinteraktionen reagiert, zu dem Zeitpunkt, zu dem die Nutzer tatsächlich mit ihr interagieren.

Der zweite Teil des Satzes ist wichtig, da bei Labortests, auch bei solchen, die Skripts für das Nutzerverhalten unterstützen, nicht genau vorhersagen kann, wann Nutzer mit einer Seite interagieren und daher die FID nicht genau messen können.

TBT berücksichtigt nicht das Nutzerverhalten

Der Lab-Messwert Total Blocking Time (TBT) ist zur Diagnose von FID-Problemen gedacht, da er quantifiziert, wie stark der Hauptthread beim Seitenaufbau blockiert wird.

Der Grundgedanke 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 der FID-Wert möglicherweise sehr niedrig.

Wann Nutzer mit einer Seite interagieren, hängt weitgehend davon ab, ob sie interaktiv aussieht oder nicht. Dies kann mit TBT nicht gemessen werden.

TBT berücksichtigt keine Antippen-Verzögerung

Wenn eine Website nicht für die Darstellung auf Mobilgeräten optimiert ist, kommt es in Browsern nach jedem Tippen zu einer Verzögerung von 300 ms, bevor Event-Handler ausgeführt werden. Dies liegt daran, dass sie erst ermitteln muss, ob der Nutzer versucht, zum Zoomen zweimal zu tippen, bevor er 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 es sich bei dieser Verzögerung jedoch technisch gesehen nicht um eine lange Aufgabe handelt, wirkt sie sich nicht auf das TBT einer Seite aus. Das bedeutet, dass eine Seite trotz sehr guter TBT-Werte einen schlechten FID-Wert aufweisen kann.

Auswirkungen des Cache-Status und des bfcaches auf FID

So wie ein ordnungsgemäßes Caching den LCP vor Ort verbessern kann, kann es auch den FID-Wert verbessern.

In der Praxis kann es vorkommen, dass sich das JavaScript für eine Website bereits im Cache eines Nutzers befindet, sodass die Verarbeitung weniger Zeit in Anspruch nehmen und die Verzögerungen geringer ausfallen könnten.

Dasselbe gilt für Seiten, die aus dem bfcache wiederhergestellt wurden. In diesen Fällen wird der JavaScript-Code aus dem Speicher wiederhergestellt, sodass nur wenig oder gar keine Verarbeitungszeit zur Verfügung steht.

CLS

Auswirkungen von Nutzerinteraktionen auf CLS

Der im Lab gemessene CLS-Wert berücksichtigt nur Layout Shifts, die „above the fold“ (ohne Scrollen sichtbar) und während des Ladens auftreten. Dies ist jedoch nur ein Teil dessen, was CLS tatsächlich misst.

Dabei berücksichtigt CLS alle unerwarteten Layoutverschiebungen, die während der Lebensdauer einer Seite auftreten. Dies schließt Inhalte ein, die sich bewegen, wenn der Nutzer scrollt, oder als Reaktion auf langsame Netzwerkanfragen nach der Nutzerinteraktion.

Beispielsweise kommt es auf Seiten häufig vor, dass Bilder oder iFrames ohne Abmessungen per Lazy Loading geladen werden. Dies kann zu Layoutverschiebungen führen, wenn ein Nutzer zu diesen Bereichen 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 gezielte Anzeigen und A/B-Tests wirken sich darauf aus, welche Elemente auf einer Seite geladen werden. Sie wirken sich auch auf das Laden aus, da personalisierte Inhalte oft später geladen und in den Hauptinhalt einer Seite eingefügt werden, was zu Layoutverschiebungen führt.

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) und langsam ladende Webschriftarten. Beide Probleme wirken sich eher auf die Nutzererfahrung aus, wenn ein Nutzer eine Website zum ersten Mal besucht und sein 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 dazu führen, dass die CLS-Werte im Feld niedriger sind als von einem Lab-Tool ausgegeben.

Vorgehensweise bei unterschiedlichen Ergebnissen

Allgemein gilt: Wenn für eine bestimmte Seite sowohl Feld- als auch Labdaten vorhanden sind, sollten Sie Ihre Arbeit anhand von Felddaten priorisieren. Da Felddaten die Erlebnisse realer Nutzer darstellen, sind sie die genaueste Methode, um wirklich zu verstehen, womit Ihre Nutzer zu kämpfen haben und was verbessert werden muss.

Wenn Ihre Felddaten jedoch in allen Bereichen gute Ergebnisse zeigen, die Labdaten aber darauf hinweisen, dass es noch Verbesserungspotenzial gibt, lohnt es sich zu verstehen, welche weiteren Optimierungen vorgenommen werden können.

Mit Felddaten werden zwar tatsächliche Nutzererfahrungen erfasst, sie jedoch nur für Nutzer, die Ihre Website erfolgreich laden können. Mit Labdaten können Sie manchmal Möglichkeiten ermitteln, die Reichweite Ihrer Website zu erweitern 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 eines verwenden, verpassen Sie möglicherweise die Gelegenheit, die Erfahrung für Ihre Nutzer zu verbessern.

Weitere Informationen