Felddaten und Chrome UX Report (CrUX)

Wenn von der Leistung einer Website die Rede ist, existieren zwei Arten zu messen nebeneinander. Die eine läuft in einer kontrollierten Umgebung ab, mit einem fest vorgegebenen Gerät, einem simulierten Netz und einem einzigen Aufruf der Seite; genau das ist es, was eine Messung im Labor hervorbringt. Die andere hält fest, was in den Browsern der Menschen passiert, die tatsächlich auf die Seite kommen, mit ihrem Handy, ihrer Verbindung und ihrem Cache.

Der Chrome UX Report, kurz CrUX, ist der öffentliche Datensatz, in dem Google diese zweite Messung veröffentlicht. Er erfasst nicht die Erfahrung von jedem beliebigen Besucher: aufgenommen werden ausschließlich Nutzer von Chrome, die den Versand von Statistiken zur Nutzung aktiviert haben, die ihren Verlauf im Browser synchronisieren und die keine Passphrase für die Synchronisierung eingerichtet haben. Draußen bleiben Chrome unter iOS, die in Android-Apps eingebetteten Webansichten und die übrigen Browser auf Chromium-Basis, dazu Safari und Firefox.

Auch die Seite muss Bedingungen erfüllen. Sie muss öffentlich auffindbar sein, nach denselben Indexierbarkeitskriterien, die eine Suchmaschine anlegt, und sie muss eine Mindestzahl an Besuchern erreichen, damit die Verteilung statistisch belastbar ist. Wie hoch dieser Schwellenwert genau liegt, veröffentlicht Google nicht.

Der Wert, den du siehst, stammt nicht aus einem einzelnen Aufruf, sondern aus einem gleitenden Fenster von 28 Tagen. Jede Aktualisierung berechnet den Datensatz mit den Daten der vorangegangenen 28 Tage neu, und deshalb braucht eine heute veröffentlichte Verbesserung mehrere Wochen, bis sie sich vollständig in den Zahlen niederschlägt.

Innerhalb dieses Fensters gibt es keine einzelne Zahl, sondern eine Verteilung von Erfahrungen. Um sie zusammenzufassen, wird das 75. Perzentil der Besuche genommen: der Wert, den 75 % der Aufrufe erreichen oder unterbieten. Das Kriterium blendet dasjenige Viertel der Besuche aus, das die schlechteste Erfahrung gemacht hat, sodass eine Seite die Bewertung bestehen kann, während eine spürbare Minderheit der Nutzer weiterhin wartet. Gemessen wird zudem getrennt nach Mobil und Desktop, und jedes Segment wird für sich bewertet.

Zu ein und denselben Daten führen mehrere Zugänge. Der Core-Web-Vitals-Bericht der Search Console aktualisiert sich täglich, hält drei Monate Historie vor und fasst ähnliche URLs zusammen, wenn eine einzelne nicht genug Messwerte sammelt. Die öffentlichen Werkzeuge zur Analyse der Geschwindigkeit zeigen den Durchschnitt über 28 Tage für die abgefragte URL und für ihre Domain an, allerdings ohne jede Historie. Die API liefert tägliche Daten auf Seiten- und Domainebene; die Verlaufs-API gibt 40 wöchentliche Zeiträume aus. Der in BigQuery abgelegte Datensatz ist monatlich, erscheint am zweiten Dienstag nach dem erfassten Zeitraum, reicht bis 2017 zurück und bietet nur die Domainebene.

Die Frage, die jedes SEO-Team erreicht, ist immer dieselbe: Warum steht die Labormessung auf Grün, während der Bericht in der Search Console weiter rot bleibt? Weil sie Verschiedenes messen. Das Labor führt einen einzigen Aufruf von einer einzigen Maschine aus, mit einem simulierten Netz und einem leeren Cache, und es kann unmöglich wissen, wann der Nutzer klicken wird. Für die Interaktivitätsmetrik meldet das Laborwerkzeug deshalb einen Ersatzwert statt der eigentlichen Metrik.

Das Feld erfasst, was das Labor nicht sieht: Mittelklasse-Handys, echte Mobilfunknetze, wiederkehrende Besuche mit warmem Cache, Wiederherstellungen aus dem Verlauf, die sofort erscheinen, Einwilligungsbanner, Werbung und personalisierte Inhalte. Ein hoher Wert im Labor zeigt lediglich, dass die Seite technisch Spielraum nach oben hat, er belegt aber nicht, dass deine Besucher sie genau so erleben.

Für die Suche zählt das Feld. Der Bericht, mit dem Google jede URL als gut oder mangelhaft einstuft, speist sich aus den Messungen echter Nutzer, und die Labormessung dient als Diagnose: sie listet wahrscheinliche Ursachen und bewährte Praktiken aus einem vordefinierten Aufruf auf. Sie hilft dabei zu erkennen, an welcher Stelle anzusetzen ist, sie erklärt das Problem damit aber noch nicht für gelöst.

• Triff die Entscheidung anhand des Berichts aus dem Feld und nutze die Messung im Labor nur dazu, die technische Ursache einzugrenzen.
• Ergänze eine eigene Messung auf der Seite, wenn dein Traffic den Schwellenwert des öffentlichen Datensatzes nicht erreicht oder wenn du nach Template, Land oder Gerät segmentieren musst.
• Sieh dir die Seitenebene an, wenn es sie gibt, und weiche nur dann auf die Domainebene aus, wenn diese URL nicht genug Messwerte sammelt.
• Rechne bei der Planung mit dem 28-Tage-Fenster und lass mindestens einen vollen Monat vergehen, bevor du ein Deployment beurteilst.
• Prüfe Mobil und Desktop getrennt, denn das zusammengefasste Ergebnis verdeckt das Segment, das durchfällt.
• Schlag die konkreten Schwellenwerte jeder Metrik in ihrem eigenen Eintrag nach, bevor du ein internes Ziel festlegst.

• Eine Seite für gut halten, weil die Labormessung 100 anzeigt, und nie wieder in den Feldbericht schauen.
• Fehlende Daten als Leistungsproblem deuten, obwohl es meist bedeutet, dass die URL zu wenige Besucher hat oder nicht indexierbar ist.
• Aus einer einzelnen Stichprobe mit abweichender Zahl schließen, der öffentliche Datensatz sei falsch, obwohl der Unterschied aus dem 28-Tage-Fenster stammt.
• Den Gesamtwert des Werkzeugs im Labor optimieren statt derjenigen Metriken, die tatsächlich im Feld bewertet werden.
• Seiten, die du messen willst, auf noindex stehen lassen oder mit einem anderen Code als 200 ausliefern, wodurch sie am Auffindbarkeitskriterium scheitern.