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 für das CrUX-Dataset schreiben und aufschlussreiche Ergebnisse zur Nutzererfahrung im Web extrahieren:
- 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`
Um die Abfrage auszuführen, geben Sie sie 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
Die Daten für jeden Messwert sind als Array von Objekten organisiert. In JSON-Notation würde first_contentful_paint.histogram.bin so aussehen:
[
{"start": 0, "end": 100, "density": 0.1234},
{"start": 100, "end": 200, "density": 0.0123},
...
]
Jeder Container enthält eine Start- und eine Endzeit in Millisekunden sowie eine Dichte, die den Prozentsatz der Nutzererfahrungen innerhalb dieses Zeitraums angibt. 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
Wir können unser Wissen über das Tabellenschema nutzen, um eine Abfrage zu schreiben, die diese Leistungsdaten extrahiert.
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 die SUM-Aggregationsfunktion verwenden, um alle entsprechenden Bin-Dichten zusammenzuzählen:
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 Sie nun die Leistungsdaten zu einem Ursprung extrahiert haben, können wir sie mit den Verlaufsdaten aus ä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-Nutzung 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% |
| … | … |
Mit diesen Techniken können Sie die Leistung für einen Ursprung abrufen, den Prozentsatz der schnellen Tests berechnen und sie im Zeitverlauf verfolgen. Versuchen Sie als Nächstes, nach zwei oder mehr Ursprüngen zu fragen und ihre Leistung zu vergleichen.
FAQ
Im Folgenden finden Sie einige der häufig gestellten Fragen zum BigQuery-Dataset für CrUX-Dateien:
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. Mit BigQuery können Sie die Daten beispielsweise sinnvoll segmentieren und sogar mit anderen öffentlichen Datasets wie dem HTTP-Archiv für erweitertes Data Mining zusammenfü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.