Cara menggunakan {i>dataset

Rick Viscomi

Data mentah Chrome UX Report (CrUX) tersedia di BigQuery, database di Google Cloud. Penggunaan BigQuery 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 data diatur
• Menulis kueri dasar untuk mengevaluasi performa asal
• Menulis kueri lanjutan untuk melacak performa dari waktu ke waktu

Organisasi data

Mulai dengan melihat kueri dasar:

SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`

Untuk menjalankan kueri, masukkan kueri ke editor kueri dan tekan tombol "Run query":

Kueri ini memiliki dua bagian:

• SELECT COUNT(DISTINCT origin) berarti membuat kueri untuk jumlah asal dalam tabel. Secara kasar, dua URL adalah bagian dari asal yang sama jika memiliki skema, host, dan port yang sama.

• FROM chrome-ux-report.all.202206 menentukan alamat tabel sumber, yang memiliki tiga bagian:

  • Nama project Cloud chrome-ux-report yang digunakan untuk mengatur semua data CrUX
  • Set data all, yang mewakili data di semua negara
  • Tabel 202206, tahun dan bulan data dalam format YYYYMM

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' (dihapus mulai Februari 2025)
• Jenis perangkat, misalnya form_factor.name = 'desktop'
• Metrik UX itu sendiri
  • first_paint (FP)
  • first_contentful_paint (FCP)
  • largest_contentful_paint (LCP)
  • dom_content_loaded (DCL)
  • onload (OL)
  • layout_instability.cumulative_layout_shift (CLS)
  • interaction_to_next_paint (INP)

Data untuk setiap metrik diatur sebagai array objek. Dalam notasi JSON, first_contentful_paint.histogram.bin akan terlihat mirip dengan 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%.

Telusuri 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.202502`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  form_factor.name = 'phone' AND
  fcp.start = 0

Hasilnya adalah 0.01115, yang berarti bahwa 1,115% pengalaman pengguna di asal ini berada antara 0 dan 100 md di 4G dan di ponsel. Jika ingin menggeneralisasi kueri ke koneksi dan jenis perangkat apa pun, kita dapat menghapusnya dari klausa WHERE dan menggunakan fungsi agregator SUM untuk menjumlahkan 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 menjumlahkan kepadatan untuk semua bin yang berada dalam rentang FCP "cepat" 0–1000 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

Hasilnya adalah 0.6977. Dengan kata lain, 69,77% pengalaman pengguna FCP di web.dev dianggap "cepat" menurut definisi rentang FCP.

Melacak performa

Setelah mengekstrak data performa tentang asal, kita dapat membandingkannya dengan data historis yang tersedia di tabel lama. Untuk melakukannya, kita dapat menulis ulang alamat tabel ke bulan sebelumnya, atau 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 cepat bervariasi beberapa poin persentase setiap bulan.

Dengan teknik ini, Anda dapat mencari performa untuk asal, menghitung persentase pengalaman cepat, dan melacaknya dari waktu ke waktu. Sebagai langkah berikutnya, coba buat kueri untuk dua asal atau lebih dan bandingkan performanya.

FAQ

Berikut beberapa pertanyaan umum (FAQ) tentang set data CrUX BigQuery:

Kapan saya harus menggunakan BigQuery, bukan alat lainnya?

BigQuery hanya diperlukan jika Anda tidak bisa mendapatkan informasi yang sama dari alat lain seperti CrUX Vis dan PageSpeed Insights. Misalnya, BigQuery memungkinkan Anda membagi data dengan cara yang bermakna dan bahkan menggabungkannya dengan set data publik lainnya seperti HTTP Archive untuk melakukan penambangan data lanjutan.

Apakah ada batasan untuk penggunaan BigQuery?

Ya, batasan terpenting adalah bahwa secara default, pengguna hanya dapat membuat kueri data senilai 1 TB per bulan. Setelah itu, tarif standar sebesar $5/TB akan berlaku.

Di mana saya dapat mempelajari BigQuery lebih lanjut?

Lihat dokumentasi BigQuery untuk mengetahui info selengkapnya.