Dipublikasikan: 31 Juli 2025
Chrome meluncurkan uji coba origin baru dari Chrome 139 untuk Soft Navigations API yang sebelumnya telah kami uji coba. Uji coba origin ini memungkinkan situs mencoba API di situs mereka dengan pengguna sungguhan untuk menguji coba API dan memberikan masukan kepada tim Chrome.
Apa itu navigasi ringan?
Navigasi ringan terjadi saat JavaScript mencegat navigasi (misalnya, mengklik link) dan memperbarui konten di halaman yang ada, bukan dengan memuat halaman baru, lalu URL diperbarui di kolom URL (dengan status histori untuk memungkinkan navigasi ringan mundur dan maju). Bagi pengguna, tampilan ini sama dengan navigasi konvensional, tetapi bagi browser, halaman tersebut tetap merupakan halaman asli.
Alasan Soft Navigation API diperlukan
Soft Navigations API adalah API yang diusulkan untuk memungkinkan deteksi berbasis heuristik dari apa yang disebut "navigasi ringan" seperti yang digunakan oleh situs Aplikasi Halaman Tunggal (SPA). Karena tidak ada navigasi halaman yang sebenarnya untuk navigasi ringan, artinya tindakan tertentu yang biasanya terjadi untuk navigasi harus dikelola secara manual oleh JavaScript. Beberapa tindakan, seperti pengelolaan histori navigasi, dapat dilakukan dengan API saat ini. Namun, tindakan lain, seperti mengukur Data Web Inti, tidak dapat dilakukan untuk navigasi ini.
Soft Navigation API memungkinkan pengamatan navigasi ringan. Meskipun JavaScript yang memulai navigasi ringan (biasanya framework JavaScript) mengetahui kapan navigasi terjadi, JavaScript lain, dan browser itu sendiri tidak akan mengetahuinya.
Core Web Vitals dan SPA
Salah satu pendorong utama untuk Soft Navigation API adalah untuk memungkinkan pengukuran Core Web Vitals untuk SPA. Data Web Inti diukur oleh browser (untuk ditampilkan di alat seperti Laporan Pengalaman Pengguna Chrome), dan oleh library JavaScript Pemantauan Pengguna Nyata (RUM).
Framework JavaScript dapat mengukur beberapa aspek Data Web Inti. Khususnya Interaction to Next Paint (INP), dan Cumulative Layout Shift (CLS) didasarkan pada primitif (Event Timing API dan Layout Instability API masing-masing) yang dapat diukur di seluruh rentang waktu untuk menghitung metrik INP dan CLS. Namun, metrik lain seperti Largest Contentful Paint (LCP) hanya dikeluarkan oleh browser—berdasarkan navigasi halaman dan diselesaikan setelah interaksi.
Cara Soft Navigation API memungkinkan pengukuran Data Web Inti untuk SPA
Iterasi pertama Soft Navigation API menggabungkan heuristik navigasi lembut dengan mereset LCP. Setelah direset, LCP dapat dipancarkan kembali untuk navigasi ringan untuk paint yang berisi konten baru, sehingga memungkinkan pengukuran metrik ini untuk navigasi ringan.
Iterasi terbaru ini menggunakan pendekatan yang berbeda dan memisahkan konsep ini menjadi Soft Navigation API dan entri performa Interaction to Contentful Paint yang baru. Entri interaction-contentful-paint mengukur "contentful paint" setelah interaksi. Untuk saat ini, peristiwa ini hanya dipancarkan untuk navigasi ringan, tetapi hal ini membuka potensi kasus penggunaan lain di luar LCP jika diaktifkan untuk semua interaksi.
API juga memperluas setiap entri performa largest-contentful-paint, interaction-contentful-paint, event-timing, dan layout-shift untuk menyertakan ID navigasi yang menjadi tujuan entri. Entri performa dikeluarkan setelah peristiwa yang diukurnya—biasanya selama waktu tidak ada aktivitas. Artinya, URL akan sering berubah pada saat entri performa dikeluarkan. Menyertakan navigasi dengan entri akan mempermudah pengukuran Data Web Inti untuk URL tertentu tanpa harus mencocokkan waktu entri performa dengan waktu entri navigasi sementara.
Mengapa menggunakan heuristik?
Soft Navigation API menganggap navigasi ringan terjadi saat hal berikut terjadi:
- Interaksi berbasis pengguna terjadi (URL diperbarui tanpa interaksi pengguna tidak dihitung)
- … yang menghasilkan modifikasi DOM dan paint
- … dan pembaruan URL terjadi
- Pembaruan URL, termasuk perubahan histori.
API ini menggunakan pendekatan berbasis heuristik ini, bukan mengizinkan framework JavaScript untuk "memancarkan" navigasi ringan, atau dibangun di atas Navigation API karena hal ini memungkinkan pemahaman yang konsisten tentang apa yang merupakan navigasi ringan, terlepas dari framework atau cara developer menggunakannya.
Framework atau developer dapat memperbarui URL untuk navigasi ringan meskipun tanpa interaksi pengguna atau update DOM yang kami anggap sebagai navigasi yang akan dilihat pengguna. Mereka juga dapat memperbarui URL pada waktu yang berbeda—di awal interaksi atau hanya di akhir saat interaksi selesai—atau pada status di antaranya.
Daripada mengandalkan pilihan framework, membangun deteksi navigasi ringan ke dalam browser menetapkan 'heuristik' kanonis (dengan masukan Anda dari uji coba origin ini) yang akan memungkinkan kami mengukur Data Web Inti untuk navigasi ringan dalam skala besar dan membuat pengukuran tersebut dapat dibandingkan dalam skala besar.
Framework dan developer juga dapat mengabaikan heuristik Soft Navigations API dan menggunakan Event Timing, Layout Instability, dan Interaction to Contentful Paint API yang mendasarinya untuk mengukur metrik performa tambahan sesuai keinginan mereka, tetapi kami merekomendasikan Core Web Vitals menggunakan heuristik untuk memungkinkan pengukuran di seluruh situs.
Bantuan yang diperlukan untuk menguji Soft Navigation API
Kami memerlukan bantuan untuk menguji Soft Navigations API guna menguji apakah heuristik cocok dengan ekspektasi Anda tentang kapan navigasi ringan terjadi. Apakah ada kasus ketika API tidak melaporkan navigasi ringan padahal Anda menganggapnya telah terjadi? Sebaliknya, apakah API melalui navigasi berulang yang tidak Anda anggap sebagai navigasi ringan?
Contoh yang kami lihat menyebabkan masalah mencakup saat URL diperbarui dengan replaceState, bukan menambahkan histori, atau saat navigasi yang tidak dimulai oleh pengguna terjadi (misalnya, logout saat waktu tunggu habis). Kedua kasus ini dijelaskan dengan tidak cocoknya heuristik dan tim Chrome merasa nyaman untuk tidak menyertakannya, tetapi kami ingin mendengar pendapat developer web jika mereka setuju. Kami ingin mendengar secara khusus kasus ketika heuristik tampaknya terpenuhi, tetapi API masih tidak mengenali navigasi lembut.
Selain itu, kami ingin memahami apakah API ini, dan primitif Interaction to Contentful Paint yang baru, memenuhi kasus penggunaan utama untuk mengizinkan pengukuran Core Web Vitals untuk SPA.
Kami ingin API ini bermanfaat semaksimal mungkin dan hal itu akan lebih mudah terjadi sebelum diluncurkan dan situs mulai bergantung pada implementasi. Oleh karena itu, kami meminta developer SPA dan mereka yang tertarik untuk mengukur performa web untuk situs ini agar mencoba API ini dan memberi tahu kami cara kerjanya bagi Anda.
Cara menguji
API dapat diuji secara lokal dengan opsi command line atau flag Chrome. Selain itu, API ini dapat diuji di lapangan dengan uji coba asal.
Lihat dokumentasi kami atau repositori GitHub untuk mengetahui detail teknis API selengkapnya, dan khususnya cara mengukur Data Web Inti. Selain itu, versi navigasi ringan eksperimental dari library web-vitals juga tersedia.
Masukan
Kami secara aktif mencari masukan tentang eksperimen ini di tempat berikut:
- Masukan tentang API harus disampaikan sebagai masalah di GitHub.
- Bug pada penerapan Chromium harus dilaporkan di pelacak masalah Chrome, jika ini belum menjadi salah satu masalah umum.
- Masukan umum web vitals dapat dikirimkan ke web-vitals-feedback@googlegroups.com.
Jika Anda ragu, jangan terlalu khawatir. Kami lebih suka mendengar masukan di kedua tempat tersebut dan akan dengan senang hati memilah masalah di kedua tempat tersebut serta mengalihkan masalah ke lokasi yang tepat.