Mengukur navigasi ringan

Barry Pollard

Michal Mocny

Dipublikasikan: 1 Februari 2023, Terakhir diperbarui: 20 September 2026

Sejak diluncurkan, inisiatif Core Web Vitals berupaya mengukur pengalaman pengguna yang sebenarnya di situs, bukan detail teknis di balik cara situs dibuat atau dimuat. Tiga metrik Core Web Vitals dibuat sebagai metrik yang berfokus pada pengguna—evolusi dari metrik teknis yang ada sepertiDOMContentLoaded atau load yang mengukur pengaturan waktu yang sering kali tidak terkait dengan cara pengguna melihat performa halaman. Oleh karena itu, teknologi yang digunakan untuk membangun situs tidak akan memengaruhi penilaian asalkan situs berperforma baik.

Kenyataannya selalu sedikit lebih rumit daripada yang ideal, dan arsitektur Aplikasi Web Satu Halaman yang populer belum pernah didukung sepenuhnya oleh metrik Core Web Vitals. Alih-alih memuat halaman web yang berbeda dan terpisah saat pengguna menjelajahi situs, aplikasi web ini menggunakan "navigasi ringan", yang konten halamannya diubah oleh JavaScript. Dalam aplikasi ini, ilusi arsitektur halaman web konvensional dipertahankan dengan mengubah URL dan mendorong URL sebelumnya dalam histori browser agar tombol kembali dan maju berfungsi seperti yang diharapkan pengguna.

Banyak framework JavaScript menggunakan model ini, tetapi masing-masing dengan cara yang berbeda. Karena hal ini berada di luar apa yang biasanya dipahami browser sebagai "halaman", mengukurnya selalu sulit: di mana batas yang harus ditarik antara interaksi di halaman saat ini, versus menganggapnya sebagai halaman baru?

Tim Chrome telah mempertimbangkan tantangan ini selama beberapa waktu, dan berupaya menstandarkan definisi "navigasi-ringan", dan cara mengukur Core Web Vitals untuk hal ini—dengan cara yang sama seperti situs yang diimplementasikan dalam arsitektur multi-halaman (MPA) konvensional diukur.

Kami telah melakukan beberapa peningkatan pada proposal berdasarkan masukan developer dan telah meluncurkan dua API performa baru untuk membantu menyelesaikan masalah ini dari Chrome 151. Selain itu, kami telah menyediakan metrik navigasi ringan di Chrome User Experience Report (CrUX) sebagai metrik eksperimental.

Apa yang dimaksud dengan navigasi ringan?

Kami telah membuat definisi navigasi sederhana berikut:

• Navigasi dimulai oleh tindakan pengguna.
• Navigasi menghasilkan perubahan URL yang terlihat oleh pengguna.
• Interaksi menghasilkan render yang terlihat.

Untuk beberapa situs, definisi ini dapat menyebabkan positif palsu (bahwa pengguna tidak akan benar-benar menganggap "navigasi" telah terjadi) atau negatif palsu (saat pengguna menganggap "navigasi" telah terjadi meskipun tidak memenuhi kriteria ini). Kami menerima masukan di repositori spesifikasi navigasi soft.

Dukungan DevTools untuk navigasi ringan

Kami telah menambahkan dukungan untuk navigasi ringan ke panel Performa DevTools dalam tampilan Metrik Live, dan dalam tampilan rekaman aktivitas dengan dukungan Insight dan penanda:

Bagaimana cara Chrome menerapkan navigasi ringan untuk developer web?

Setelah fitur navigasi ringan diaktifkan (selengkapnya di bagian berikutnya), Chrome akan mengubah cara melaporkan beberapa metrik performa:

• Peristiwa soft-navigation PerformanceTiming akan ditampilkan setelah setiap navigasi sederhana terdeteksi.
• Entri soft-navigation ini akan menyertakan navigationId, URL baru di atribut name, serta interactionId interaksi yang memulai.
• Satu atau beberapa entri interaction-contentful-paint akan ditampilkan setelah interaksi yang menyebabkan contentful paint. Entri ini akan berisi entri largestContentfulPaint yang dapat digunakan untuk mengukur Largest Contentful Paint (LCP) untuk navigasi ringan.
• Atribut navigationId ditambahkan ke setiap pengaturan waktu performa (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event, dan layout-shift). Atribut ini sesuai dengan entri navigasi tempat peristiwa dikeluarkan. Perhatikan bahwa jika entri ini mencakup navigasi multi-halaman, entri tersebut mungkin berisi navigationId sebelumnya atau berikutnya, bergantung pada kapan entri tersebut dikeluarkan. Selengkapnya tentang hal ini di bagian Melaporkan metrik terhadap URL yang sesuai.
• soft-navigation akan menyertakan fungsi getLargestInteractionContentfulPaint() untuk mengambil entri interaction-contentful-paint terbesar untuk navigasi tersebut. Nilai ini kemudian dapat digunakan sebagai LCP awal untuk navigasi tersebut, dan LCP tersebut kemudian dapat diperbarui saat lebih banyak entri interaction-contentful-paint untuk interaksi tersebut diamati. Perhatikan bahwa atribut ini menggantikan atribut largestInteractionContentfulPaint yang tersedia dalam uji coba origin sebelumnya.
• Beberapa entri interaction-contentful-paint mungkin terjadi sebelum navigasi singkat berlangsung (jika update URL tidak terjadi hingga setelah render tersebut). Dalam kasus ini, fungsi getLargestInteractionContentfulPaint() menghindari perlunya melakukan buffering dan melihat kembali entri lama setelah navigasi ringan diselesaikan. Perhatikan bahwa entri yang ditampilkan oleh getLargestInteractionContentfulPaint() adalah salinan persis dari entri interaction-contentful-paint terbesar pada saat entri tersebut ditampilkan, sehingga entri tersebut mungkin telah menggunakan navigationId sebelumnya karena saat itulah render terjadi, tetapi render ini harus diukur terhadap navigationId baru.
• Entri soft-navigation juga akan menyertakan paintTime dan presentationTime sebagai FCP untuk navigasi tersebut.
• Perlu diketahui bahwa entri interaction-contentful-paint juga akan ditampilkan setelah interaksi lebih lanjut, tetapi LCP untuk URL harus dibatasi pada entri interaction-contentful-paint yang cocok dengan interactionId navigasi singkat untuk mengecualikan entri ini dan juga hanya untuk properti largestContentfulPaint di dalamnya.

Perubahan ini akan memungkinkan Core Web Vitals—dan beberapa metrik diagnostik terkait—diukur per navigasi halaman, meskipun ada beberapa nuansa yang perlu dipertimbangkan.

Apa implikasi dari mengaktifkan navigasi ringan di Chrome?

Berikut adalah beberapa perubahan yang perlu dipertimbangkan pemilik situs setelah mengaktifkan fitur ini:

• Pemantauan entri soft-navigation memungkinkan "pemisahan" entri performa ke dalam setiap "navigasi".
• Metrik CLS dan INP sudah dapat dibagi sesuai kebijaksanaan Anda, bukan diukur selama durasi seluruh siklus proses halaman, tetapi fitur Navigasi Ringan memberikan ukuran standar kapan hal ini terjadi, terlepas dari teknologi dasar yang digunakan.
• Entri largest-contentful-paint diselesaikan pada interaksi (yang diperlukan untuk memulai navigasi ringan), sehingga hanya dapat digunakan untuk mengukur LCP navigasi "hard" awal. Artinya, hal ini tidak akan berubah saat navigasi ringan diukur sehingga LCP untuk pemuatan halaman awal, navigasi berat, dapat diukur seperti biasa.
• Entri interaction-contentful-paint baru yang akan ditampilkan dari interaksi dapat digunakan untuk mengukur LCP untuk navigasi lembut dengan melihat properti largestContentfulPaint di dalamnya, tetapi ada beberapa pertimbangan tentang cara menggunakan entri ini yang akan kita bahas dalam artikel ini.
• Perhatikan bahwa tidak semua pengguna akan mendukung fitur navigasi ringan ini, terutama bagi mereka yang menggunakan browser lain atau Chrome versi sebelum 151. Perhatikan bahwa beberapa pengguna mungkin tidak melaporkan metrik berbasis navigasi ringan, meskipun mereka melaporkan metrik Core Web Vitals.

Tanyakan kepada penyedia RUM Anda apakah mereka mendukung pengukuran Core Web Vitals dengan navigasi ringan. Banyak yang berencana menguji standar baru ini, dan akan mempertimbangkan pertimbangan sebelumnya. Sementara itu, beberapa penyedia juga mengizinkan pengukuran terbatas untuk metrik performa berdasarkan heuristik mereka sendiri.

Untuk mengetahui informasi selengkapnya tentang cara mengukur metrik untuk navigasi ringan, lihat bagian Mengukur Core Web Vitals per navigasi ringan.

Bagaimana cara mengaktifkan navigasi ringan di Chrome?

Fitur navigasi ringan diaktifkan secara default mulai Chrome 151.

Mendeteksi dukungan Soft Navigations API

Anda dapat menggunakan kode berikut untuk menguji apakah API didukung:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

Atau:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

Bagaimana cara mengukur navigasi ringan?

Jika didukung, metrik dapat dilaporkan menggunakan API PerformanceObserver seperti metrik lainnya. Namun, ada beberapa pertimbangan tambahan yang perlu diperhitungkan untuk metrik ini.

Melaporkan navigasi ringan

Anda dapat menggunakan PerformanceObserver untuk mengamati navigasi ringan. Berikut adalah contoh cuplikan kode yang mencatat entri navigasi tidak kentara ke konsol—termasuk navigasi tidak kentara sebelumnya di halaman ini menggunakan opsi buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Hal ini dapat digunakan untuk menyelesaikan metrik halaman siklus proses penuh untuk navigasi sebelumnya.

Melaporkan metrik terhadap URL yang sesuai

Saat navigasi sederhana terlihat, Core Web Vitals halaman sebelumnya harus diselesaikan, lalu dilaporkan untuk URL sebelumnya, dan pemantauan baru harus dimulai untuk URL baru.

Atribut name dari entri soft-navigation yang sesuai akan berisi URL baru untuk melaporkan metrik, dan navigationId akan menjadi referensi unik untuk navigasi ini (karena URL yang sama dapat dikunjungi beberapa kali selama masa aktif aplikasi web satu halaman).

Nilai ini harus ditetapkan sebagai setiap entri soft-navigation dan digunakan untuk melaporkan metrik hingga entri soft-navigation berikutnya diterima.

Laporkan URL yang benar untuk interaction-contentful-paint

Pertimbangan tambahan diperlukan untuk menghitung LCP dari entri interaction-contentful-paint, karena tidak semua entri interaction-contentful-paint harus dipetakan menggunakan navigationId dan dilaporkan sebagai LCP untuk URL tersebut:

• Masalah pertama adalah entri interaction-contentful-paint dapat ditampilkan sebelum navigasi singkat terjadi jika render terjadi sebelum update URL. Dalam kasus ini, navigationId akan ditujukan untuk URL lama. Jika URL diperbarui terlebih dahulu, rendering akan menyelesaikan navigasi umum dan dalam hal ini entri soft-navigation akan ditampilkan terlebih dahulu, dan interaction-contentful-paint akan memiliki URL baru.
• Masalah kedua adalah interaction-contentful-paint, entri akan terus ditampilkan untuk interaksi yang lebih baru, karena cakupan metrik performa ini melampaui LCP untuk navigasi ringan. Kita hanya ingin mempertimbangkan render untuk pemuatan navigasi umum untuk LCP, bukan untuk interaksi berikutnya.

Oleh karena itu, interactionId, bukan navigationId, harus digunakan untuk memetakan entri interaction-contentful-paint ke soft-navigation-entries guna mendapatkan URL yang benar. Tindakan ini akan menangani entri apa pun dengan navigationId lama serta memfilter entri interaction-contentful-paint yang tidak boleh dipertimbangkan untuk LCP.

Selain itu, Anda harus memproses fungsi getLargestInteractionContentfulPaint() dari entri soft-navigation terlebih dahulu, untuk menangani entri interaction-contentful-paint yang terjadi sebelum soft-navigation entries ditampilkan.

Mendapatkan startTime navigasi ringan

Semua pengaturan waktu performa, termasuk untuk navigasi ringan, dan entri yang digunakan untuk menghitung metrik Core Web Vitals dilaporkan sebagai waktu dari waktu navigasi halaman "berat" awal. Oleh karena itu, waktu mulai navigasi ringan harus dikurangi dari waktu metrik pemuatan navigasi ringan (misalnya LCP), untuk melaporkannya secara relatif terhadap waktu navigasi ringan ini.

Waktu mulai navigasi dapat diperoleh dengan cara yang sama dengan memetakan ke entri soft-navigation yang sesuai dan menggunakan startTime-nya.

startTime adalah waktu interaksi awal (misalnya, klik tombol) yang memulai navigasi ringan. Hal ini agak berbeda dengan "hard navigation", yang "waktu mulai"-nya adalah saat halaman baru "di-commit" ke browser, dan setelah beberapa kode pengendali peristiwa dijalankan. Waktu mulai navigasi ringan juga mencakup kode pengendali peristiwa tersebut karena kami mengukur dari waktu mulai interaksi.

Mengukur Core Web Vitals per navigasi ringan

Untuk mengukur Core Web Vitals, dengarkan entri soft-navigation, reset metrik saat menerima entri ini. FCP dapat ditampilkan berdasarkan presentationTime dan LCP dapat diinisialisasi ke entri getLargestInteractionContentfulPaint(). INP, CLS, harus diinisialisasi ke 0 seperti saat pemuatan halaman.

LCP, INP, dan CLS kemudian dapat diukur dan dipantau seperti biasa (dengan pengecualian penggunaan interaction-contentful-paint untuk LCP yang memberikan kecocokan interactionId). interactionId dapat digunakan untuk memberi nama entri ke URL seperti yang dibahas sebelumnya.

Waktu akan tetap ditampilkan relatif terhadap waktu mulai navigasi "hard" yang asli. Jadi, untuk menghitung LCP untuk navigasi sederhana, misalnya, Anda harus mengambil pengaturan waktu interaction-contentful-paint dan mengurangi waktu mulai navigasi sederhana yang sesuai seperti yang dijelaskan sebelumnya untuk mendapatkan pengaturan waktu yang relatif terhadap navigasi sederhana.

Beberapa metrik biasanya diukur selama masa aktif halaman: LCP, misalnya, dapat berubah hingga interaksi terjadi. CLS dan INP dapat diperbarui hingga halaman ditinggalkan, terlepas dari interaksi apa pun. Oleh karena itu, metrik navigasi sebelumnya harus diselesaikan saat setiap navigasi sementara baru terjadi. Artinya, metrik navigasi "sulit" awal dapat diselesaikan lebih awal dari biasanya saat mengukur Core Web Vitals dengan navigasi ringan.

Demikian pula, saat mulai mengukur metrik untuk navigasi soft baru dari metrik yang berumur panjang ini, metrik harus "direset" atau "diinisialisasi ulang" dan diperlakukan sebagai metrik baru, tanpa mengingat nilai yang ditetapkan untuk "halaman" sebelumnya. Artinya, pemahaman tentang paint "terbesar", interaction to next paint, atau pergeseran tata letak direset untuk memungkinkan pengukuran lagi dari awal.

Bagaimana seharusnya konten yang tetap sama di antara navigasi diperlakukan?

LCP untuk navigasi ringan (dihitung dari interaction-contentful-paint) hanya akan mengukur render baru, dan hanya render yang terkait dengan interaksi yang menyebabkan navigasi. Hal ini dapat menghasilkan LCP yang berbeda dari pemuatan cold navigasi soft tersebut ke pemuatan soft.

Misalnya, ambil halaman yang menyertakan gambar banner besar yang merupakan elemen LCP, tetapi teks di bawahnya berubah dengan setiap navigasi lembut. Pemuatan halaman awal akan menandai gambar banner sebagai elemen LCP dan mendasarkan pengaturan waktu LCP pada elemen tersebut. Untuk navigasi soft berikutnya, teks di bawahnya akan menjadi elemen terbesar yang dirender setelah navigasi soft dan akan menjadi elemen LCP baru. Namun, jika halaman dimuat dengan deep link ke URL navigasi umum, gambar banner akan menjadi render baru sehingga akan memenuhi syarat untuk dipertimbangkan sebagai elemen LCP.

Demikian pula, animasi dapat memperbarui bagian halaman secara terus-menerus—tidak terkait dengan navigasi lembut yang terjadi. Render baru apa pun karena animasi latar belakang tersebut tidak akan dipertimbangkan untuk LCP untuk navigasi lembut baru. Namun, elemen tersebut dapat dipertimbangkan untuk LCP jika halaman dimuat ulang dari URL ini.

Seperti yang ditunjukkan contoh ini, elemen LCP untuk navigasi ringan dapat dilaporkan secara berbeda bergantung pada cara halaman dimuat—dengan cara yang sama seperti memuat halaman dengan link anchor di bagian bawah halaman dapat menghasilkan elemen LCP yang berbeda untuk navigasi berat.

Bagaimana cara mengukur TTFB?

Time to First Byte (TTFB) untuk pemuatan halaman konvensional menunjukkan waktu saat byte pertama permintaan asli ditampilkan.

Untuk navigasi lembut, ini adalah pertanyaan yang lebih rumit. Haruskah kita mengukur permintaan pertama yang dibuat untuk halaman baru? Bagaimana jika semua konten sudah ada di aplikasi dan tidak ada permintaan tambahan? Bagaimana jika permintaan tersebut dibuat terlebih dahulu dengan pengambilan data di awal? Bagaimana jika permintaan tidak terkait dengan navigasi sederhana dari perspektif pengguna (misalnya, permintaan analisis)?

Metode yang lebih sederhana adalah melaporkan TTFB 0 untuk navigasi lembut—dengan cara yang sama seperti yang kami rekomendasikan untuk pemulihan back/forward cache. Ini adalah metode yang digunakan library web-vitals untuk navigasi ringan dan yang kami rekomendasikan untuk metrik ini saat ini.

Haruskah Anda mengukur Core Web Vitals dengan kedua metodologi tersebut?

Meskipun API baru ini hanya tersedia untuk browser berbasis Chromium, situs mungkin ingin mengukur keduanya dengan mengelompokkan berdasarkan navigasi ringan, dan dengan terus mengelompokkan berdasarkan navigasi berat. Hal ini akan memungkinkan perbandingan di berbagai browser dan untuk tren historis.

Untuk LCP, ini berarti hanya mempertimbangkan entri largest-contentful-paint untuk cara saat ini, dan entri largest-contentful-paint dan interaction-contentful-paint untuk cara baru.

Untuk CLS dan INP, ini berarti mengukurnya di seluruh siklus proses halaman seperti yang dilakukan saat ini, dan membagi linimasa secara terpisah berdasarkan navigasi ringan untuk mengukur nilai CLS dan INP yang terpisah untuk navigasi baru.

Metrik kemudian perlu dikirim dan disimpan dua kali untuk analisis.

Menggunakan library web-vitals untuk mengukur Core Web Vitals untuk navigasi ringan

Cara termudah untuk memperhitungkan semua nuansa adalah dengan menggunakan library JavaScript web-vitals yang memiliki dukungan untuk navigasi ringan mulai v6.0.0. Hal ini dapat diukur dengan cara berikut (ganti doTraditionalProcessing dan doSoftNavProcessing sebagaimana mestinya):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

Library web-vitals juga memastikan Anda melaporkan metrik terhadap URL yang benar seperti yang disebutkan sebelumnya, karena library ini menyertakan navigationId dan navigationURL dalam entri yang diberikan ke callback.

Library web-vitals melaporkan metrik berikut untuk navigasi ringan:

Apakah perubahan ini akan menjadi bagian dari pengukuran Core Web Vitals?

Tujuan utamanya adalah menyediakan sarana untuk mengukur performa dengan lebih baik seperti yang dialami oleh pengguna sungguhan. Jadi, tujuannya adalah untuk menyertakan metrik ini dalam pengukuran Core Web Vitals seperti yang ditampilkan oleh semua alat setelah API diluncurkan.

Bagaimana navigasi ringan akan dilaporkan di CrUX?

Kami telah meluncurkan versi eksperimental metrik Core Web Vitals di CrUX. Metrik ini mengakhiri CLS dan INP "hard nav" setelah navigasi ringan pertama dan juga menyertakan pengukuran LCP, CLS, dan INP tambahan untuk setiap navigasi ringan. Kami berencana untuk meningkatkan metrik eksperimental ini menjadi metrik stabil pada Mei 2027. Untuk mengetahui informasi selengkapnya, lihat postingan blog Metrik navigasi halus eksperimental kini tersedia di CrUX.

Bagaimana cara menangani navigasi ringan di browser lain?

Navigasi ringan sulit dideteksi secara terprogram di browser yang tidak mendukung API—itulah alasan kami mengerjakan API ini.

Anda dapat menggunakan Navigation API untuk memantau perubahan URL yang dapat memungkinkan pemisahan INP berdasarkan URL (dan juga CLS, meskipun saat ini hanya tersedia di Chromium sehingga tidak akan diukur). Namun, hal ini tidak mengatasi metrik render (FCP dan LCP) yang hanya dapat diperkirakan.

Pada saat yang sama, kami yakin insight yang ditawarkan oleh API ini terlalu berharga untuk diabaikan, baik dalam mengukur waktu navigasi ringan maupun dalam mengatribusikan metrik ke navigasi yang benar. Sebaiknya gunakan API baru ini meskipun saat ini belum ada dukungan lintas browser. Sama seperti saat Core Web Vitals diluncurkan, masalah yang diidentifikasi, dan solusi performa kemungkinan akan memengaruhi semua browser meskipun visibilitasnya saat ini terbatas hanya untuk browser berbasis Chromium.

Kami akan terus berupaya melalui proses standardisasi dan berinteraksi dengan vendor browser lain untuk menunjukkan pentingnya API ini.

Masukan

Kami secara aktif mencari masukan tentang API ini di tempat-tempat berikut:

• Masukan tentang API harus diajukan sebagai masalah di GitHub.
• Bug pada implementasi Chromium harus dilaporkan di Issue Tracker Chrome, jika belum termasuk dalam masalah umum.
• Masukan umum terkait web vitals dapat dikirimkan ke web-vitals-feedback@googlegroups.com.

Jika ragu, jangan terlalu khawatir. Kami lebih suka menerima masukan di salah satu tempat dan akan dengan senang hati melakukan triase masalah di kedua tempat serta mengalihkan masalah ke lokasi yang benar.

Log perubahan

Seiring pengembangan API ini, sejumlah perubahan telah terjadi, lebih banyak daripada API stabil. Anda dapat melihat Log Perubahan Navigasi Ringan untuk mengetahui detail selengkapnya.

Kesimpulan

Fitur Navigasi Ringan adalah pendekatan menarik terkait cara inisiatif Core Web Vitals dapat berkembang untuk mengukur pola umum di web modern yang tidak ada dalam metrik kami. Kami telah mengumpulkan banyak masukan dari komunitas web yang lebih luas dan kami terdorong oleh potensi API ini.

Ucapan terima kasih

Gambar thumbnail oleh Jordan Madrid di Unsplash

Pekerjaan ini merupakan kelanjutan dari pekerjaan yang pertama kali dimulai oleh Yoav Weiss saat dia berada di Google. Kami berterima kasih kepada Yoav atas upayanya dalam API ini.