Die Rohdaten des Chrome UX-Berichts (CrUX) sind in BigQuery, einer Datenbank in Google Cloud, verfügbar. Für die Verwendung von BigQuery benötigen Sie ein GCP-Projekt und grundlegende Kenntnisse von SQL.
In diesem Leitfaden erfahren Sie, wie Sie mit BigQuery Abfragen an den CrUX-Datensatz stellen, um aussagekräftige Ergebnisse zur Nutzerfreundlichkeit im Web zu erhalten:
- Datenorganisation
- Grundlegende Abfrage zum Bewerten der Leistung eines Ursprungs erstellen
- Erweiterte Abfrage zum Überwachen der Leistung im Zeitverlauf schreiben
Datenorganisation
Sehen wir uns zuerst eine einfache Abfrage an:
SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`
Geben Sie die Abfrage in den Abfrageeditor ein und klicken Sie auf die Schaltfläche „Abfrage ausführen“:
Diese Abfrage besteht aus zwei Teilen:
SELECT COUNT(DISTINCT origin)bedeutet, dass nach der Anzahl der Ursprünge in der Tabelle gefragt wird. Grob gesagt gehören zwei URLs zur selben Quelle, wenn sie dasselbe Schema, denselben Host und denselben Port haben.FROM chrome-ux-report.all.202206gibt die Adresse der Quelltabelle an, die aus drei Teilen besteht:- Der Name des Cloud-Projekts
chrome-ux-report, in dem alle CrUX-Daten organisiert sind - Der Datensatz
allmit Daten für alle Länder - Die Tabelle
202206, das Jahr und der Monat der Daten im Format JJJJMM
- Der Name des Cloud-Projekts
Es gibt auch Datensätze für jedes Land. chrome-ux-report.country_ca.202206 steht beispielsweise nur für die Daten zur Nutzererfahrung aus Kanada.
Jedes Dataset enthält Tabellen für jeden Monat seit 201710. Neue Tabellen für den vorherigen Kalendermonat werden regelmäßig veröffentlicht.
Die Struktur der Datentabellen (auch als Schema bezeichnet) enthält:
- Der Ursprung, z. B.
origin = 'https://www.example.com', der die zusammengefasste Verteilung der Nutzerfreundlichkeit für alle Seiten auf dieser Website darstellt - Die Verbindungsgeschwindigkeit zum Zeitpunkt des Seitenaufbaus, z. B.
effective_connection_type.name = '4G' - Der Gerätetyp, z. B.
form_factor.name = 'desktop' - Die UX-Messwerte selbst
Die Daten für jeden Messwert sind als Array von Objekten organisiert. In JSON-Notation würde first_contentful_paint.histogram.bin in etwa so aussehen:
[
{"start": 0, "end": 100, "density": 0.1234},
{"start": 100, "end": 200, "density": 0.0123},
...
]
Jeder Bin enthält einen Start- und einen Endzeitpunkt in Millisekunden sowie eine Dichte, die den Prozentsatz der Nutzererfahrungen in diesem Zeitraum darstellt. Mit anderen Worten: Bei 12,34% der FCP-Erfahrungen für diesen hypothetischen Ursprung, diese Verbindungsgeschwindigkeit und diesen Gerätetyp liegt die Latenz unter 100 ms. Die Summe aller Bin-Dichten beträgt 100%.
Die Struktur der Tabellen in BigQuery ansehen
Leistung auswerten
Anhand unseres Wissens über das Tabellenschema können wir eine Abfrage schreiben, mit der diese Leistungsdaten extrahiert werden.
SELECT
fcp
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
effective_connection_type.name = '4G' AND
form_factor.name = 'phone' AND
fcp.start = 0
Das Ergebnis ist 0.01115.Das bedeutet, dass 1,115% der Nutzererfahrungen an diesem Ursprung zwischen 0 und 100 ms bei 4G und auf einem Smartphone liegen. Wenn wir unsere Abfrage auf jede Verbindung und jeden Gerätetyp verallgemeinern möchten, können wir sie aus der WHERE-Klausel auslassen und mit der SUM-Aggregatfunktion alle entsprechenden Bin-Dichten addieren:
SELECT
SUM(fcp.density)
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start = 0
Das Ergebnis ist 0.05355, also 5,355% auf allen Geräten und Verbindungstypen. Wir können die Abfrage leicht ändern und die Dichten für alle Bins im Bereich „schnell“ (0–1.000 ms) addieren:
SELECT
SUM(fcp.density) AS fast_fcp
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start < 1000
Das ergibt 0.6977. Mit anderen Worten: 69, 77% der FCP-Nutzererfahrungen auf web.dev gelten gemäß der Definition des FCP-Bereichs als „schnell“.
Leistungserfassung
Nachdem wir Leistungsdaten zu einer Quelle extrahiert haben, können wir sie mit den Verlaufsdaten in älteren Tabellen vergleichen. Dazu können wir die Tabellenadresse auf einen früheren Monat umschreiben oder die Platzhaltersyntax verwenden, um alle Monate abzufragen:
SELECT
_TABLE_SUFFIX AS yyyymm,
SUM(fcp.density) AS fast_fcp
FROM
`chrome-ux-report.all.*`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start < 1000
GROUP BY
yyyymm
ORDER BY
yyyymm DESC
Hier sehen wir, dass der Prozentsatz der schnellen FCP-Aufrufe jeden Monat um einige Prozentpunkte schwankt.
| yyyymm | fast_fcp |
|---|---|
| 202206 | 69,77% |
| 202205 | 70,71% |
| 202204 | 69,04% |
| 202203 | 69,82% |
| 202202 | 67,75% |
| 202201 | 58,96% |
| 202112 | 41,69% |
| … | … |
So können Sie die Leistung für einen Ursprung abrufen, den Prozentsatz der schnellen Seitenaufrufe berechnen und im Zeitverlauf beobachten. Im nächsten Schritt können Sie nach zwei oder mehr Ursprüngen fragen und ihre Leistung vergleichen.
FAQ
Im Folgenden finden Sie einige häufig gestellte Fragen zum BigQuery-Dataset „CrUX“:
Wann sollte ich BigQuery anstelle anderer Tools verwenden?
BigQuery ist nur dann erforderlich, wenn Sie dieselben Informationen nicht mit anderen Tools wie dem CrUX-Dashboard und PageSpeed Insights erhalten können. In BigQuery können Sie die Daten beispielsweise sinnvoll segmentieren und sogar mit anderen öffentlichen Datasets wie dem HTTP-Archiv zusammenführen, um fortgeschrittenes Data-Mining durchzuführen.
Gibt es Einschränkungen bei der Verwendung von BigQuery?
Ja, die wichtigste Einschränkung ist, dass Nutzer standardmäßig nur Daten im Umfang von 1 TB pro Monat abfragen können. Darüber hinaus gilt der Standardpreis von 5 $/TB.
Wo erhalte ich weitere Informationen zu BigQuery?
Weitere Informationen finden Sie in der BigQuery-Dokumentation.