Dipublikasikan: 11 Februari 2025
Rilis Laporan Pengalaman Pengguna Chrome (CrUX) pada Februari 2025 menyertakan sejumlah metrik baru (dan yang diubah) yang menarik:
- Subbagian gambar dan jenis resource Largest Contentful Paint (LCP)
- Detail Waktu Round Trip (RTT)
- Penghapusan dimensi Jenis Koneksi Efektif (ECT)
Masing-masing memberikan insight yang lebih besar tentang metrik performa origin dan URL yang tersedia di CrUX, dan dalam postingan ini kami akan menjelaskan alasannya.
Informasi diagnostik LCP
Kami awalnya memperkenalkan konsep subbagian LCP di Google I/O 2022 sebagai teknik yang efektif untuk membagi waktu LCP untuk halaman dengan LCP gambar menjadi komponen yang lebih kecil untuk memastikan Anda menghabiskan upaya untuk mengoptimalkan penyebab LCP yang tinggi.
Analisis data lab HTTP Archive dalam diskusi tersebut menunjukkan bahwa waktu download gambar sering kali merupakan bagian terkecil dari waktu LCP. Banyak alat lab (termasuk Lighthouse Google sendiri) sering kali berfokus pada saran untuk mengoptimalkan format dan ukuran gambar guna mengurangi waktu download dan meningkatkan performa. Meskipun masih benar, analisis menunjukkan bahwa saran tersebut mungkin terlalu ditekankan dan masalah yang lebih besar adalah penundaan sebelum gambar ditemukan oleh browser dan mulai didownload.
Meskipun menganalisis data lab dapat berguna, cara web digunakan dalam kehidupan nyata sering kali berbeda sehingga kemampuan untuk melihat subbagian ini untuk data lapangan sangatlah penting. Postingan yang dipublikasikan tahun lalu mengonfirmasi kesalahpahaman umum tentang cara mengoptimalkan LCP dengan data kolom.
Subbagian gambar LCP
Dengan rilis ini, pemilik situs dapat memeriksa situs mereka sendiri untuk menemukan subbagian LCP gambar, di tingkat origin atau URL.
Subbagian hanya tersedia untuk gambar dan tidak mencakup gambar bingkai video pertama (yang sedikit lebih rumit karena kami tidak dapat mengukur waktu download penuh). Subbagian teks juga tidak disertakan karena kurang berguna dan akan mendistorsi angka LCP gambar. Untuk situs yang sebagian besar terdiri dari LCP teks, metrik TTFB keseluruhan dan metrik FCP keseluruhan adalah perincian yang berguna—meskipun perlu diperhatikan bahwa metrik tersebut berlaku untuk semua LCP, bukan khusus untuk LCP teks. Terakhir, subbagian gambar hanya dikumpulkan pada pemuatan halaman penuh—tidak seperti metrik LCP itu sendiri yang juga dikumpulkan pada navigasi kembali-maju dan halaman pra-rendering.
Data ini telah ditambahkan ke CrUX API dan CrUX History API mulai Februari 2025 (catatan: bukan BigQuery). CrUX History API memiliki data selama dua minggu saat diluncurkan, dan data ini akan bertambah seiring waktu hingga menjadi histori lengkap selama 25 minggu. API ini menyediakan data sebagai persentil ke-75 dari setiap subbagian yang dinyatakan dalam milidetik.
Misalnya, untuk mendapatkan subbagian gambar LCP untuk https://web.dev/ untuk kunjungan halaman PHONE, Anda dapat menggunakan perintah curl berikut (ganti API_KEY dengan kunci Anda sendiri):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": [
"largest_contentful_paint_image_time_to_first_byte",
"largest_contentful_paint_image_resource_load_delay",
"largest_contentful_paint_image_resource_load_duration",
"largest_contentful_paint_image_element_render_delay"]}'
Dan Anda akan mendapatkan respons seperti ini:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_image_element_render_delay": {
"percentiles": {
"p75": 2088
}
},
"largest_contentful_paint_image_resource_load_delay": {
"percentiles": {
"p75": 828
}
},
"largest_contentful_paint_image_resource_load_duration": {
"percentiles": {
"p75": 417
}
},
"largest_contentful_paint_image_time_to_first_byte": {
"percentiles": {
"p75": 2385
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Kami telah memperbarui alat CrUX Vis untuk menyertakan data ini dan berharap alat pihak ketiga lainnya yang menggunakan CrUX API juga mengekspos data berharga ini:
Dalam contoh ini, kita dapat melihat bahwa untuk situs media populer, durasi pemuatan resource adalah komponen terkecil. Peluang sebenarnya untuk peningkatan situs ini terletak pada TTFB, dan penundaan pemuatan resource, dengan peluang yang lebih kecil pada penundaan rendering elemen.
Nilai tinggi di setiap subbagian menunjukkan masalah yang berbeda:
- Time to First Byte (TTFB) yang tinggi biasanya menunjukkan masalah server, jaringan, atau pengalihan seperti yang dijelaskan di Mengoptimalkan TTFB.
- Penundaan pemuatan resource yang tinggi menunjukkan bahwa gambar LCP ditemukan terlambat oleh browser—misalnya, gambar LCP yang dimasukkan oleh JavaScript sisi klien yang memerlukan waktu beberapa saat untuk dijalankan.
- Durasi pemuatan resource yang tinggi adalah saat Anda harus mempertimbangkan untuk mengurangi ukuran download gambar.
- Penundaan rendering elemen yang tinggi adalah saat gambar tersedia (mungkin melalui
<link rel=preload>, tetapi tidak digunakan dalam waktu lama—lagi-lagi sering kali karena JavaScript sisi klien diperlukan untuk menampilkan gambar.
Kami harap dengan menyediakan data ini di CrUX pada tingkat origin dan URL (tunduk pada kriteria kelayakan biasa), situs dapat lebih mudah mengoptimalkan metrik LCP mereka.
Jenis resource LCP
Karena subbagian paling baik dilihat untuk LCP gambar, CrUX membatasi data ini hanya untuk halaman yang berisi gambar. Oleh karena itu, penting untuk memahami berapa banyak LCP Anda yang merupakan LCP gambar, bukan LCP teks (misalnya, judul <h1> dan paragraf panjang).
Selain subbagian gambar LCP, CrUX API kini juga menyertakan pengelompokan resource yang menunjukkan pemisahan pemuatan halaman LCP antara teks dan gambar.
Misalnya, untuk mendapatkan jenis resource LCP untuk https://web.dev/ untuk kunjungan halaman PHONE, Anda dapat menggunakan perintah curl berikut (sekali lagi, ganti API_KEY dengan kunci Anda sendiri):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["largest_contentful_paint_resource_type"]}'
Dan Anda akan mendapatkan respons seperti ini:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_resource_type": {
"fractions": {
"image": 0.0155,
"text": 0.9845
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Vis CrUX juga telah diperbarui untuk menampilkan data ini:
Misalnya, untuk halaman beranda web.dev, kita dapat melihat bahwa 98,5% LCP sebenarnya adalah LCP teks, sehingga subbagian gambar LCP kurang berguna untuk halaman ini. Dalam hal ini, kita dapat menggunakan metrik TTFB dan FCP asli sebagai pengelompokan diagnostik yang berpotensi lebih baik.
Jenis resource LCP adalah alat diagnostik lain yang berguna untuk memahami dan meningkatkan LCP, terutama untuk mengetahui seberapa berguna subbagian gambar LCP.
Informasi diagnostik RTT
Kami juga telah memperluas metrik RTT yang pertama kali diperkenalkan pada Agustus 2024.
Tiga bin RTT
Kami telah menambahkan tiga bin ke CrUX API yang menampilkan tiga pengelompokan kepadatan RTT:
| Latensi Jaringan | Mulai | End |
|---|---|---|
| Rendah | 0 milidetik | < 75 milidetik |
| Sedang | 75 milidetik | < 275 milidetik |
| Tinggi | 275 milidetik | ∞ |
Bucket ini lebih informatif daripada kategori ECT sebelumnya yang menyertakan semua yang kurang dari 270 milidetik dalam kategori 4g. Dengan kemajuan teknologi jaringan sejak kategori tersebut diluncurkan, sebagian besar situs melihat sebagian besar traffic mereka berada dalam kategori tersebut sehingga kategorisasi ini kurang berguna.
Oleh karena itu, sebaiknya gunakan label rendah, sedang, dan tinggi untuk distribusi, bukan label baik, perlu ditingkatkan, dan buruk seperti biasa. Metrik ini bukan metrik yang dapat ditingkatkan langsung oleh pemilik situs, sehingga merupakan metrik diagnostik untuk memahami metrik lainnya dan alasan metrik tersebut mungkin berbeda dari yang diharapkan. Metrik ini juga dapat membantu menjelaskan alasan metrik lain berubah dari waktu ke waktu, meskipun situs tidak berubah jika metrik tersebut menunjukkan perubahan pada basis pengguna.
Bucket ini tersedia di CrUX API, misalnya untuk web.dev untuk kunjungan halaman PHONE (sekali lagi, ganti API_KEY dengan kunci Anda sendiri):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["round_trip_time"]}'
Yang akan menampilkan sesuatu seperti ini:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"round_trip_time": {
"histogram": [
{
"start": 0,
"end": 75,
"density": 0.1524
},
{
"start": 75,
"end": 275,
"density": 0.6641
},
{
"start": 275,
"density": 0.1835
}
],
"percentiles": {
"p75": 230
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Bucket ditampilkan di CrUX Vis saat distribusi dipilih:
RTT di BigQuery
Selain memperluas metrik RTT di CrUX API untuk menyertakan tri-bin, kami juga telah menyediakan data dalam set data BigQuery bulanan, termasuk histogram lengkap dalam bucket 25 milidetik di tabel mentah serta nilai tri-bin dan p75 di tabel yang diwujudkan.
Hal ini memungkinkan pemahaman yang lebih mendalam tentang distribusi data di luar tiga bin yang tersedia di CrUX API. Hal ini juga memungkinkan kami membuat ulang pengelompokan ECT yang telah dihapus dari CrUX mulai bulan ini (selengkapnya nanti)—dengan sedikit perubahan pada nilai minimum 275 milidetik untuk 4g, bukan nilai minimum 270 milidetik sebelumnya. Perincian ECT (sekarang bersumber dari data RTT) terus tersedia di tabel BigQuery CrUX yang diwujudkan sehingga alat seperti Dasbor CrUX dapat terus menampilkan perincian ini.
Set data BigQuery juga menyertakan data menurut negara (sebagaimana ditentukan oleh ISO 3166-1). Hal ini memungkinkan analisis yang lebih mendalam yang dapat berguna untuk menjelaskan alasan metrik performa lebih buruk bagi beberapa pengguna. Misalnya, kita dapat melihat data untuk pengguna Google Phone dengan melihat data untuk https://www.google.com:
SELECT
`chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
least(500, p75_rtt) AS capped_p75_rtt,
p75_rtt
FROM
`chrome-ux-report.materialized.country_summary`
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202501 AND
device = 'phone'
ORDER BY
p75_rtt DESC,
country_code
Kemudian, kita memvisualisasikan data di peta Geo:
https://www.google.com(data sumber dengan diagram interaktif).
Kita dapat melihat bahwa, meskipun sebagian besar dunia (terutama "dunia Barat") memiliki RTT yang sangat baik, Afrika Sub-Sahara, sebagian Timur Tengah, dan sebagian Asia mengalami kesulitan lebih besar. Bahkan,grafik dibatasi pada RTT 500 milidetik karena penggunaan data lengkap akan mendistorsi warna—terutama dengan Eritrea pada persentil ke-75 sebesar 3.850 milidetik.
Hal ini juga dapat berguna saat pola traffic berubah. Misalnya, proporsi pengguna yang lebih besar dari negara-negara tersebut dengan RTT yang lebih tinggi dapat menjelaskan statistik Core Web Vitals yang lebih buruk meskipun situs tidak mengubah apa pun.
Meskipun situs tidak dapat langsung meningkatkan RTT, menyediakan data ini oleh pengunjung situs memungkinkan pemahaman yang lebih baik tentang pengguna situs Anda di seluruh dunia. Hal ini juga menimbulkan banyak peluang untuk analisis di masa mendatang dan kami berharap peneliti akan menemukan insight yang menarik dari set data ini.
Penghapusan dimensi ECT
Perubahan terakhir dalam rilis Februari 2025 adalah penghentian dimensi Jenis Koneksi Efektif (ECT) dari BigQuery (kami telah menghapus RTT dari API mulai September 2024 saat kami memperkenalkan metrik RTT sebagai penggantinya).
Seperti yang disebutkan sebelumnya dalam postingan ini, metrik RTT memungkinkan tampilan yang lebih terperinci tentang detail koneksi pengunjung situs. Anda bahkan dapat membuat ulang bucket ECT dari histogram tersebut. (Secara teknis, ECT harus berupa kombinasi RTT dan kecepatan downlink, tetapi Chrome hanya pernah menggunakan RTT.)
Perbedaan penting adalah ECT adalah dimensi CrUX—yang berarti metrik lainnya dapat disegmentasikan menurut ECT. RTT adalah metrik CrUX, bukan dimensi, sehingga Anda tidak dapat melihat LCP menurut RTT, misalnya, tetapi hanya dapat melihat RTT menurut dimensi lainnya (jenis perangkat dan negara).
Hal ini mungkin terdengar lebih membatasi, tetapi perubahan dari dimensi menjadi metrik sebenarnya membuka lebih banyak data di CrUX. Hal ini karena CrUX memiliki nilai minimum tertentu sebelum kami dapat menampilkan data. Kami telah membuat dimensi bersifat opsional pada tahun 2022, yang berarti kami menghapus ECT, atau perangkat jika diperlukan untuk melaporkan pada tingkat yang lebih tinggi, tetapi metrik yang tidak ada di sebagian besar pemuatan halaman (Interaksi ke Gambar Berikutnya (INP), jenis navigasi yang berbeda, dan sekarang subbagian gambar LCP) sering kali tidak tersedia untuk origin di BigQuery.
Dengan mengurangi jumlah dimensi, data menjadi kurang tersegmentasi, sehingga jumlah origin yang memenuhi persyaratan minimum ini meningkat. Pada bulan Januari, kami melaporkan INP untuk 68,1% asal, sedangkan untuk set data Desember, kami hanya melaporkan INP untuk 64,5% asal. Mekanisme ini juga berlaku untuk Jenis Navigasi, Subbagian LCP, dan Jenis Resource dalam rilis ini—semuanya mendapatkan manfaat dari penghapusan dimensi ECT. Di CrUX API, peningkatan cakupan telah berlaku sejak awal Februari.
Kolom ECT akan tetap ada di BigQuery untuk konsistensi dengan set data sebelumnya, dan data ECT dalam tampilan terwujud akan tetap tersedia, tetapi berdasarkan informasi RTT (dengan perbedaan 5 milidetik untuk 3g dan 4g seperti yang disebutkan sebelumnya) selain RTT p75 dan tri-bin baru.
Kesimpulan
Penambahan lebih banyak metrik ke set data CrUX publik memberi pemilik situs dan peneliti lebih banyak informasi untuk membantu mendiagnosis dan pada akhirnya memperbaiki masalah performa.
Sebagai set data publik, CrUX memiliki batasan tertentu pada tingkat detail yang dapat kami tampilkan—misalnya, pemilih elemen individual tidak akan pernah dapat ditampilkan di CrUX. Pemilik situs yang menginginkan tingkat detail ini sangat disarankan untuk menerapkan solusi RUM, yang tidak akan dibatasi.
Namun, data gabungan tingkat tinggi seperti yang dijelaskan dalam postingan ini dapat membantu menjembatani kesenjangan antara mengetahui bahwa Anda memiliki masalah dan mengetahui penyebab masalah tersebut. Kami harap data tambahan ini bermanfaat. Beri tahu kami di grup diskusi jika Anda memiliki masukan atau pertanyaan.