Jenis navigasi kini tersedia di CrUX

Barry Pollard

Johannes Henkel

Mulai dari set data Maret 2024, Laporan Pengalaman Pengguna (CrUX) Chrome menyertakan metrik navigation_types. Laporan ini memberikan statistik gabungan tentang jenis navigasi pemuatan halaman untuk dimensi yang dikueri.

Jenis navigasi yang berbeda mengakibatkan perbedaan dalam metrik performa. Jadi, saat melihat performa situs Anda, sebaiknya pahami frekuensi relatif dari berbagai jenis tersebut. Misalnya, saat navigasi menggunakan back forward (bfcache), navigasi tersebut biasanya menghasilkan navigasi yang hampir instan, yang tercermin dalam metrik LCP dan FCP yang sangat kecil, serta pengurangan metrik CLS dan INP.

Dengan mengekspos perincian jenis navigasi, kami berharap dapat mendorong pemilik situs agar lebih memperhatikan jenis navigasi yang digunakan di situs mereka, dan berupaya mendorong beberapa jenis navigasi yang lebih cepat dengan melihat penyiapan penyimpanan dalam cache, pemblokir bfcache, dan pra-rendering.

Metrik navigation_types tersedia di CrUX API harian, CrUX History API (dengan histori selama 3 minggu yang tersedia di awal dan akan terus bertambah 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). Bagian 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:

Dalam beberapa kasus, 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, perincian pelaporannya terbatas. Untuk banyak origin dan URL, metrik navigation_types tidak tersedia karena traffic yang memenuhi syarat tidak memadai. Lihat metodologi CrUX untuk informasi selengkapnya.

Selain itu, CrUX tidak dapat memberikan perincian metrik lain berdasarkan jenis navigasi, karena akan semakin mengurangi jumlah origin dan URL yang tersedia di CrUX.

Sebaiknya situs menerapkan Pemantauan Pengguna Nyata (RUM) sendiri agar dapat mengelompokkan traffic berdasarkan kriteria seperti jenis navigasi. Perhatikan bahwa Anda mungkin melihat perbedaan jenis navigasi di 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 tingkat detail yang lebih lengkap tentang masalah performa tertentu. Misalnya, meskipun CrUX mungkin menyiratkan bahwa akan lebih baik jika Anda meningkatkan kelayakan bfcache, bfcache notRestoreAlasans API dapat menginformasikan dengan tepat mengapa 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 dalam dokumentasi API, termasuk penjelasan tentang cara mendapatkan kunci API dan panduan API. Tindakan ini akan menampilkan 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 pecahan 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 yang diberikan.

Anda dapat melihat dari respons ini bahwa untuk periode pengumpulan mulai 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. Perhatikan bahwa untuk setiap kunci tertentu (termasuk kombinasi URL atau origin dan faktor bentuk), pecahan 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 fraksi, yang memungkinkan visualisasi pecahan ini dari waktu ke waktu. Untuk mengubah permintaan Anda dari CrUX API ke CrUX History API, jalankan permintaan terhadap endpoint queryHistoryRecord, bukan queryRecord. Misalnya, CrUX History Colab kami memetakan metrik navigation_types sebagai batang bertumpuk:

Pada screenshot sebelumnya, histori hanya tersedia untuk 3 periode pengumpulan (masing-masing 28 hari, selang waktu 7 hari). Setelah terisi penuh, data ini akan mencakup seluruh 25 periode pengumpulan. Dengan memvisualisasikan histori ini, Anda dapat mengonfirmasi bahwa pengoptimalan telah diterapkan atau mengalami kemunduran. 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 terbuat dari setiap jenis, sedangkan tampilan ringkasan yang terwujud mencakup beberapa kolom navigation_types_*—satu kolom untuk setiap jenis.

Tabel mendetail

Skema tabel mendetail di CrUX BigQuery memberikan histogram mendetail untuk metrik performa web, yang memungkinkan kami menampilkan dalam contoh analisis ini bagaimana jenis navigasi tertentu dapat dikorelasikan dengan performa pemuatan instan atau yang baik.

Sebagai contoh, kita melihat fraksi back_forward_cache dan korelasinya dengan seberapa sering halaman dimuat secara instan (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 (DIV=0,87) — ditunjukkan dalam plot berikut — dan korelasi sedang antara back_forward_cache dan good_lcp_density (web=0,29).

Colab untuk analisis ini mendapat komentar yang banyak; di sini, kita hanya membahas kueri yang mengekstrak fraksi navigation_types untuk 10 ribu asal paling populer dari tabel mendetail di CrUX BigQuery:

• Kita mengakses tabel all.202403 di sini (lihat klausa FROM), dan memfilter form_factor untuk phone dan memilih origin dengan peringkat popularitas <= 10000 untuk 10 ribu origin teratas (lihat klausa WHERE).
• Saat membuat kueri metrik navigation_types di BigQuery, Anda perlu membagi dengan total pecahan navigation_types, karena hanya akan bertambah per asal, tetapi tidak per kombinasi (asal, faktor bentuk).
• Tidak semua origin akan memiliki navigation_types, jadi praktik yang baik adalah menggunakan SAVE_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, sering kali lebih tepat (dan lebih murah) untuk membuat kueri tabel yang diwujudkan. Misalnya, kueri berikut mengekstrak data navigation_types yang tersedia dari tabel chrome-ux-report.materialized.device_summary. Tabel ini disertakan 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 yang akan diinterpretasikan oleh kueri.

Alasannya adalah fraksi navigation_type dalam chrome-ux-report.materialized.device_summary—seperti kepadatan histogram—menambah hingga 1,0 per origin, bukan per origin dan perangkat per tanggal. Hal ini memungkinkan Anda melihat distribusi jenis navigasi di berbagai perangkat:

SELECT
  device,
  navigation_types_back_forward
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403

Dalam hasil kueri ini, pecahan tersebut 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 pada phone menunjukkan bahwa kita dapat mencoba mengoptimalkan pemuatan halaman ini sehingga dapat ditayangkan dari bfcache.

Namun, penting juga untuk mempertimbangkan bagian pemuatan halaman yang sudah dilayani oleh bfcache—yaitu, rasio hit bfcache. Kueri berikut menunjukkan bahwa origin tertentu ini mungkin sudah dioptimalkan dengan baik, mengingat > 60% rasio hit 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

Jadi, akan terlihat bahwa tarif back_forward yang tinggi di ponsel bukan karena penggunaan bfcache yang lebih sedikit, tetapi lebih mencerminkan cara pengguna menavigasi mundur dan maju 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 dari 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, di bagian atas halaman Dasbor ini.

Kesimpulan

Kami harap pengelompokan jenis navigasi di CrUX bermanfaat dan membantu Anda memahami serta mengoptimalkan performa situs. Dengan memastikan penggunaan cache HTTP, bfcache, dan pra-rendering yang efisien, situs dapat mencapai pemuatan halaman yang jauh lebih cepat daripada pemuatan halaman yang memerlukan perjalanan kembali ke server.

Kami juga menyediakan data tersebut di semua titik akses CrUX sehingga pengguna dapat menggunakan data tersebut sesuai keinginan dan melihat pengelompokan jenis menurut URL untuk yang diekspos di CrUX API.

Kami ingin mendengar masukan tentang tambahan CrUX ini di media sosial atau di grup diskusi CrUX.