Dimulai dari set data Maret 2024, Laporan Pengalaman Pengguna (CrUX) Chrome menyertakan metrik navigation_types. Hal ini memberikan statistik gabungan tentang jenis navigasi pemuatan halaman untuk dimensi yang dikueri.
Jenis navigasi yang berbeda menyebabkan perbedaan pada metrik performa. Jadi, saat melihat performa situs, sebaiknya pahami frekuensi relatif dari berbagai jenis tersebut. Misalnya, saat navigasi menggunakan maju mundur (bfcache), yang biasanya menghasilkan navigasi seketika, yang tercermin dalam metrik LCP dan FCP yang sangat kecil, serta pengurangan metrik CLS dan INP.
Dengan mengekspos pengelompokan jenis navigasi, kami berharap dapat mendorong pemilik situs untuk lebih menyadari jenis navigasi yang digunakan di situs mereka, dan terlihat mendorong beberapa jenis navigasi yang lebih cepat dengan melihat penyiapan cache, pemblokir bfcache, dan pra-rendering.
Metrik navigation_types tersedia di CrUX API harian, CrUX History API (dengan histori 3 minggu tersedia pada awalnya dan meningkat setiap minggu hingga cakupan penuh selama 6 bulan ke depan), set data CrUX BigQuery terbaru, dan Dasbor CrUX. Memiliki histori juga memungkinkan pemilik situs melihat perubahan penggunaan jenis navigasi dari waktu ke waktu. Tindakan ini dapat memungkinkan pelacakan peningkatan (misalnya, menghapus pemblokiran bfcache). Halaman ini juga dapat membantu menjelaskan perubahan pada metrik meskipun tidak ada perubahan yang dilakukan pada situs mereka.
Jenis navigasi apa yang tersedia di CrUX?
CrUX membedakan jenis navigasi berikut dalam tabel berikut:
| Jenis | Deskripsi |
|---|---|
navigate |
Pemuatan halaman, yang tidak masuk dalam kategori lainnya. |
navigate_cache |
Pemuatan halaman yang resource utamanya (dokumen HTML utama) disalurkan dari cache HTTP. Situs sering kali menggunakan cache untuk sub-resource, tetapi dokumen HTML utama sering di-cache jauh lebih sedikit. Jika memungkinkan, hal ini bisa menghasilkan peningkatan performa yang signifikan karena kemampuannya untuk disimpan dalam cache secara lokal dan di CDN. |
reload |
Pengguna memuat ulang halaman, baik dengan menekan tombol muat ulang, dengan menekan enter di kolom URL, atau dengan mengurungkan penutupan tab. Pemuatan ulang halaman sering kali mengakibatkan validasi ulang kembali ke server untuk memeriksa apakah halaman utama telah berubah. Persentase pemuatan ulang halaman yang tinggi dapat mengindikasikan pengguna yang frustrasi. |
restore |
Halaman dimuat ulang setelah browser dimulai ulang, atau tab yang telah dihapus karena alasan memori. Untuk Chrome di Android, setelan ini dilaporkan sebagai reload. |
back_forward |
Navigasi histori, artinya halaman telah dilihat dan kembali baru-baru ini. Dengan caching yang benar, pengalaman ini akan menjadi pengalaman yang cukup cepat, tetapi masih memerlukan halaman untuk diproses dan JavaScript harus dijalankan—keduanya dihindari oleh bfcache. |
back_forward_cache |
Navigasi histori yang ditampilkan dari bfcache. Mengoptimalkan halaman untuk memanfaatkan bfcache akan menghasilkan pengalaman yang lebih cepat. Situs harus berupaya menghapus pemblokir bfcache untuk meningkatkan persentase navigasi dalam kategori ini. |
prerender |
Halaman ini dipra-render, yang—mirip dengan bfcache—dapat mengakibatkan pemuatan halaman hampir seketika. |
Terkadang, pemuatan halaman dapat berupa kombinasi dari beberapa jenis navigasi. Dalam hal ini, CrUX melaporkan kecocokan pertama dalam urutan terbalik dari tabel sebelumnya (dari bawah ke atas).
Keterbatasan jenis navigasi di CrUX
Karena CrUX adalah {i>dataset<i} publik, tingkat perincian pelaporannya terbatas. Untuk sebagian besar origin dan URL, metrik navigation_types tidak tersedia karena traffic yang memenuhi syarat tidak memadai. Lihat metodologi CrUX untuk mengetahui informasi selengkapnya.
Selain itu, CrUX tidak dapat memberikan perincian metrik lainnya berdasarkan jenis navigasi, karena hal ini akan semakin mengurangi jumlah origin dan URL yang tersedia di CrUX.
Sebaiknya situs menerapkan Pemantauan Pengguna Asli (RUM) miliknya sendiri agar dapat mengelompokkan traffic berdasarkan kriteria seperti jenis navigasi. Perhatikan bahwa Anda mungkin melihat perbedaan jenis navigasi dalam solusi ini bergantung pada jenis yang dilaporkan, dan kunjungan halaman mana yang disertakan—lihat artikel Mengapa data CrUX berbeda dengan data RUM saya?.
RUM juga dapat memberikan detail yang lebih lengkap tentang masalah performa tertentu. Misalnya, meskipun CrUX mungkin menyiratkan bahwa peningkatan kelayakan bfcache akan bermanfaat, bfcache notRevertReasons API dapat memberi tahu dengan tepat alasan pemuatan halaman tertentu tidak dapat ditayangkan dari bfcache.
Jenis navigasi di CrUX API
Untuk melihat jenis navigasi di API, sertakan metrik navigation_types dalam permintaan, atau jangan tetapkan metrik sehingga semua metrik akan disertakan:
export API_KEY="[YOUR_API_KEY]"
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
--header 'Content-Type: application/json' \
--data '{"origin": "https://example.com", metrics: ["navigation_types"]}'
Format permintaan dijelaskan secara lebih mendetail di dokumentasi API, termasuk penjelasan tentang cara mendapatkan kunci API Anda, dan panduan API. Tindakan ini akan mengembalikan objek seperti ini:
{
"record": {
"key": { "origin": "https://example.com" },
"metrics": {
"navigation_types": {
"fractions": {
"navigate": 0.5335,
"navigate_cache": 0.2646,
"reload": 0.0885,
"restore": 0.0023,
"back_forward": 0.0403,
"back_forward_cache": 0.0677,
"prerender": 0.0031
}
}
},
"collectionPeriod": {
"firstDate": { "year": 2024, "month": 3, "day": 6 },
"lastDate": { "year": 2024, "month": 4, "day": 2 }
}
}
}
Dalam responsnya, CrUX melaporkan metrik navigation_types sebagai objek dengan fraksi pemuatan halaman untuk setiap jenis navigasi. Setiap pecahan adalah nilai antara 0.0 (menunjukkan 0% pemuatan halaman) hingga 1.0, (menunjukkan 100% pemuatan halaman) untuk kunci tertentu.
Anda dapat melihat dari respons ini bahwa untuk periode pengumpulan yang dimulai pada 6 Maret 2024—hingga dan termasuk 2 April 2024 - 6,77% navigasi (pemuatan halaman) ditayangkan dari bfcache browser. Demikian juga, beberapa bagian lainnya dapat membantu mengidentifikasi peluang untuk pengoptimalan pemuatan halaman. Perlu diketahui bahwa untuk kunci tertentu (termasuk kombinasi URL atau origin dan faktor bentuk), fraksi navigation_types akan berjumlah sekitar 1,0.
Jenis navigasi di CrUX History API
CrUX History API dapat menyediakan deret waktu untuk jenis navigasi dengan hingga 25 titik data per pecahan, yang memungkinkan visualisasi pecahan ini dari waktu ke waktu. Untuk mengubah permintaan Anda dari CrUX API ke CrUX History API, jalankan di endpoint queryHistoryRecord, bukan queryRecord. Misalnya, CrUX History Colab memetakan metrik navigation_types sebagai batang bertumpuk:
Dalam screenshot sebelumnya, histori hanya tersedia untuk 3 periode pengumpulan (masing-masing 28 hari, selang 7 hari). Setelah terisi penuh, ini akan mencakup 25 periode pengumpulan. Memvisualisasikan histori ini memungkinkan konfirmasi bahwa pengoptimalan telah diterapkan atau telah mengalami regresi. Hal ini terutama berlaku untuk konfigurasi cache HTTP, yang mengoptimalkan halaman untuk bfcache dan pra-rendering.
Jenis navigasi di CrUX BigQuery
Tabel BigQuery CrUX kini menyertakan data navigation_type, yang dibuat dari setiap jenis, sedangkan tampilan ringkasan terwujud mencakup beberapa kolom navigation_types_*—satu untuk setiap jenis.
Tabel mendetail
Skema tabel mendetail di BigQuery CrUX menyediakan histogram mendetail untuk metrik performa web, yang memungkinkan kita menunjukkan dalam contoh analisis ini bagaimana jenis navigasi tertentu dapat berkorelasi dengan performa pemuatan instan atau yang baik.
Sebagai contoh, kami melihat fraksi back_forward_cache dan korelasinya dengan seberapa sering halaman dimuat seketika (instant_lcp_density didefinisikan sebagai LCP <= 200 md) dan seberapa sering LCP yang baik terlihat (good_lcp_density didefinisikan sebagai LCP <= 2.500 md). Kami mengamati korelasi statistik yang kuat antara back_forward_cache dan instant_lcp_density (upayakan = 0,87 ) —yang ditunjukkan pada plot berikut — dan korelasi sedang antara back_forward_cache dan good_lcp_density (Pengambilan 0,29 ).
Colab untuk analisis ini banyak dikomentari; di sini, kita hanya membahas kueri yang mengekstrak fraksi navigation_types untuk 10 ribu origin paling populer dari tabel mendetail di CrUX BigQuery:
- Kita mengakses tabel
all.202403di sini (lihat klausaFROM), lalu filterform_factoruntukphonedan pilih origin dengan peringkat popularitas <= 10000 untuk 10 ribu origin terpopuler (lihat klausaWHERE). - Saat membuat kueri metrik
navigation_typesdi BigQuery, Anda perlu membaginya dengan total pecahannavigation_types, karena pecahan tersebut hanya akan ditambahkan per asal, tetapi tidak per kombinasi (asal, faktor bentuk). - Tidak semua origin akan memiliki
navigation_types, jadi sebaiknya gunakanSAVE_DIVIDE.
WITH tmp AS (
SELECT
origin,
SUM(navigation_types.navigate.fraction) AS navigate,
SUM(navigation_types.navigate_cache.fraction) AS navigate_cache,
SUM(navigation_types.reload.fraction) AS reload,
SUM(navigation_types.restore AS restore,
SUM(navigation_types.back_forward.fraction) AS back_forward,
SUM(navigation_types.back_forward_cache.fraction) AS back_forward_cache,
SUM(navigation_types.prerender.fraction) AS prerender,
SUM(navigation_types.navigate.fraction
+ navigation_types.navigate_cache.fraction
+ navigation_types.reload.fraction
+ navigation_types.restore.fraction
+ navigation_types.back_forward.fraction
+ navigation_types.back_forward_cache.fraction
+ navigation_types.prerender.fraction) AS total
FROM
`chrome-ux-report.all.202403`
WHERE
experimental.popularity.rank <= 10000 AND
form_factor.name = 'phone'
GROUP BY
origin
)
SELECT
origin,
ROUND(SAFE_DIVIDE(navigate, total), 4) AS navigate,
ROUND(SAFE_DIVIDE(navigate_cache, total), 4) AS navigate_cache,
ROUND(SAFE_DIVIDE(reload, total), 4) AS reload,
ROUND(SAFE_DIVIDE(restore, total), 4) AS restore,
ROUND(SAFE_DIVIDE(back_forward, total), 4) AS back_forward,
ROUND(SAFE_DIVIDE(back_forward_cache, total), 4) AS back_forward_cache,
ROUND(SAFE_DIVIDE(prerender, total), 4) AS prerender
FROM
tmp
Tabel terwujud
Jika ringkasan sudah memadai, akan lebih efektif (dan lebih murah) untuk mengkueri tabel terwujud. Misalnya, kueri berikut mengekstrak data navigation_types yang tersedia dari tabel chrome-ux-report.materialized.device_summary. Tabel ini diurutkan berdasarkan bulan, asal, dan jenis perangkat.
SELECT
yyyymm,
device,
navigation_types_navigate,
navigation_types_navigate_cache,
navigation_types_reload,
navigation_types_restore,
navigation_types_back_forward,
navigation_types_back_forward_cache,
navigation_types_prerender
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://example.com' AND
navigation_types_navigate IS NOT NULL
ORDER BY
yyyymm DESC,
device DESC
Perhatikan bahwa pecahan ini tidak akan berjumlah 1,0 per baris, jadi Anda perlu membagi setiap pecahan dengan jumlah hasil kueri yang akan ditafsirkan.
Alasan untuk hal ini adalah fraksi navigation_type dalam chrome-ux-report.materialized.device_summary—seperti kepadatan histogram—menambahkan hingga 1,0 per asal, bukan per origin dan perangkat per tanggal. Hal ini memungkinkan Anda melihat distribusi jenis navigasi di seluruh perangkat:
SELECT
device,
navigation_types_back_forward
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202403
device |
navigation_types_back_forward |
|---|---|
phone |
0.0663 |
desktop |
0.0179 |
tablet |
0.0009 |
Dalam hasil kueri ini, pecahan mencerminkan persentase pemuatan halaman untuk https://www.google.com asal: 6,63% pemuatan halaman ini memiliki jenis navigasi back_forward di ponsel, 1,79% desktop, dan 0,09% tablet.
Persentase back_forward yang jauh lebih tinggi di phone menunjukkan bahwa kita dapat mencoba mengoptimalkan pemuatan halaman ini agar dapat ditayangkan dari bfcache.
Namun, penting juga untuk mempertimbangkan berapa bagian dari pemuatan halaman yang telah disalurkan oleh bfcache—yaitu, rasio hit bfcache. Kueri berikut menunjukkan bahwa origin tertentu ini mungkin sudah dioptimalkan dengan baik, mengingat rasio hit-nya > 60% untuk ponsel dan desktop.
SELECT
device,
navigation_types_back_forward_cache /
(navigation_types_back_forward + navigation_types_back_forward_cache)
AS back_forward_cache_hit_rate
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202403
device |
back_forward_cache_hit_rate |
|---|---|
phone |
0.6239 |
desktop |
0.6805 |
tablet |
0.7353 |
Jadi, akan muncul bahwa rasio back_forward yang tinggi di ponsel bukan karena penggunaan bfcache yang lebih rendah, tetapi lebih merupakan refleksi tentang cara pengguna menavigasi mundur dan maju lebih banyak di ponsel.
Jenis navigasi di Dasbor CrUX
Cara termudah untuk melihat jenis navigasi adalah di Dasbor CrUX, yang dapat diakses untuk origin dari link ini. Seperti yang Anda lihat pada screenshot berikut, hanya data selama satu bulan yang awalnya tersedia, tetapi seiring waktu, histori akan terisi sehingga Anda dapat melihat perubahan jenis dari bulan ke bulan.
Seperti yang juga dapat Anda lihat, kami telah menyoroti jenis navigasi yang lebih cepat, yang harus dioptimalkan oleh tempat wisata tersebut, di bagian atas halaman Dasbor ini.
Kesimpulan
Kami harap pengelompokan jenis navigasi di CrUX berguna dan dapat membantu Anda memahami serta mengoptimalkan performa situs. Dengan memastikan penggunaan cache HTTP, bfcache, dan pra-rendering secara efisien, situs dapat mencapai pemuatan halaman yang jauh lebih cepat daripada pemuatan halaman yang memerlukan perjalanan kembali ke server.
Kami juga dapat menyediakan data di semua titik akses CrUX sehingga pengguna dapat memakai data sesuai keinginan mereka dan melihat perincian jenis berdasarkan URL untuk URL yang diekspos dalam CrUX API.
Kami ingin mendengar masukan tentang penambahan CrUX ini di media sosial atau di grup diskusi CrUX.