Data mentah Laporan UX Chrome (CrUX) tersedia di BigQuery, database di Google Cloud. Untuk menggunakan BigQuery, Anda memerlukan project GCP dan pengetahuan dasar tentang SQL.
Dalam panduan ini, pelajari cara menggunakan BigQuery untuk menulis kueri terhadap set data CrUX guna mengekstrak hasil yang bermanfaat tentang status pengalaman pengguna di web:
- Memahami cara pengaturan data
- Menulis kueri dasar untuk mengevaluasi performa origin
- Menulis kueri lanjutan untuk melacak performa dari waktu ke waktu
Pengaturan data
Mulai dengan melihat kueri dasar:
SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`
Untuk menjalankan kueri, masukkan kueri ke editor kueri, lalu tekan tombol "Jalankan kueri":
Ada dua bagian dalam kueri ini:
SELECT COUNT(DISTINCT origin)berarti membuat kueri untuk jumlah asal dalam tabel. Secara garis besar, dua URL adalah bagian dari origin yang sama jika memiliki skema, host, dan port yang sama.FROM chrome-ux-report.all.202206menentukan alamat tabel sumber, yang memiliki tiga bagian:- Nama project Cloud
chrome-ux-reporttempat semua data CrUX diatur - Set data
all, yang mewakili data di semua negara - Tabel
202206, tahun dan bulan data dalam format YYYYMM
- Nama project Cloud
Ada juga set data untuk setiap negara. Misalnya, chrome-ux-report.country_ca.202206 hanya mewakili data pengalaman pengguna yang berasal dari Kanada.
Dalam setiap set data, ada tabel untuk setiap bulan sejak 201710. Tabel baru untuk bulan kalender sebelumnya dipublikasikan secara rutin.
Struktur tabel data (juga dikenal sebagai skema) berisi:
- Asal, misalnya
origin = 'https://www.example.com', yang mewakili distribusi pengalaman pengguna gabungan untuk semua halaman di situs tersebut - Kecepatan koneksi pada saat pemuatan halaman, misalnya,
effective_connection_type.name = '4G' - Jenis perangkat, misalnya
form_factor.name = 'desktop' - Metrik UX itu sendiri
Data untuk setiap metrik diatur sebagai array objek. Dalam notasi JSON, first_contentful_paint.histogram.bin akan terlihat seperti ini:
[
{"start": 0, "end": 100, "density": 0.1234},
{"start": 100, "end": 200, "density": 0.0123},
...
]
Setiap bin berisi waktu mulai dan waktu berakhir dalam milidetik serta kepadatan yang mewakili persentase pengalaman pengguna dalam rentang waktu tersebut. Dengan kata lain, 12,34% pengalaman FCP untuk asal, kecepatan koneksi, dan jenis perangkat hipotetis ini kurang dari 100 md. Jumlah semua kepadatan bin adalah 100%.
Jelajahi struktur tabel di BigQuery.
Mengevaluasi performa
Kita dapat menggunakan pengetahuan tentang skema tabel untuk menulis kueri yang mengekstrak data performa ini.
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
Hasilnya adalah 0.01115, yang berarti bahwa 1,115% pengalaman pengguna di origin ini berada antara 0 dan 100 md di 4G dan di ponsel. Jika ingin membuat generalisasi kueri ke koneksi dan jenis perangkat apa pun, kita dapat menghapusnya dari klausa WHERE dan menggunakan fungsi agregator SUM untuk menambahkan semua kepadatan bin masing-masing:
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
Hasilnya adalah 0.05355, atau 5,355% di semua perangkat dan jenis koneksi. Kita dapat sedikit mengubah kueri dan menambahkan kepadatan untuk semua bin yang berada dalam rentang FCP "cepat" 0–1.000 md:
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
Hal ini memberi kita 0.6977. Dengan kata lain, 69,77% pengalaman pengguna FCP di web.dev dianggap "cepat" sesuai dengan definisi rentang FCP.
Lacak performa
Setelah mengekstrak data performa tentang origin, kita dapat membandingkannya dengan data historis yang tersedia di tabel lama. Untuk melakukannya, kita dapat menulis ulang alamat tabel ke bulan sebelumnya, atau kita dapat menggunakan sintaksis karakter pengganti untuk membuat kueri semua bulan:
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
Di sini, kita melihat bahwa persentase pengalaman FCP yang cepat bervariasi sebesar beberapa poin persentase setiap bulan.
| yyyymm | fast_fcp |
|---|---|
| 202206 | 69,77% |
| 202205 | 70,71% |
| 202204 | 69,04% |
| 202203 | 69,82% |
| 202202 | 67,75% |
| 202201 | 58,96% |
| 202112 | 41,69% |
| ... | ... |
Dengan teknik ini, Anda dapat mencari performa untuk origin, menghitung persentase pengalaman yang cepat, dan melacaknya dari waktu ke waktu. Sebagai langkah berikutnya, coba buat kueri untuk dua origin atau lebih dan bandingkan performanya.
FAQ
Berikut beberapa pertanyaan umum (FAQ) tentang set data BigQuery CrUX:
Kapan saya harus menggunakan BigQuery, bukan alat lain?
BigQuery hanya diperlukan jika Anda tidak dapat memperoleh informasi yang sama dari alat lain seperti Dasbor CrUX dan PageSpeed Insights. Misalnya, BigQuery memungkinkan Anda mengelompokkan data dengan cara yang bermakna dan bahkan menggabungkannya dengan set data publik lainnya seperti HTTP Archive untuk melakukan beberapa eksplorasi data lanjutan.
Apakah ada batasan untuk menggunakan BigQuery?
Ya, batasan yang paling penting adalah secara default pengguna hanya dapat membuat kueri data senilai 1 TB per bulan. Selain itu, tarif standar sebesar $5/TB akan berlaku.
Di mana saya dapat mempelajari BigQuery lebih lanjut?
Lihat dokumentasi BigQuery untuk mengetahui info selengkapnya.