Bereksperimen dengan pengukuran navigasi ringan

Barry Pollard

Michal Mocny

Dipublikasikan: 1 Februari 2023, Terakhir diperbarui: 31 Juli 2025

Sejak peluncurannya, inisiatif Data Web Inti berupaya mengukur pengalaman pengguna 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 waktu yang sering kali tidak terkait dengan cara pengguna melihat performa halaman. Oleh karena itu, teknologi yang digunakan untuk membangun situs tidak akan memengaruhi pemberian skor jika situs berperforma baik.

Kenyataannya selalu sedikit lebih rumit daripada yang ideal, dan arsitektur Aplikasi Halaman Tunggal yang populer tidak pernah didukung sepenuhnya oleh metrik Data Web Inti. Daripada memuat halaman web yang berbeda dan terpisah saat pengguna menjelajahi situs, aplikasi web ini menggunakan apa yang disebut "navigasi ringan", di mana konten halaman diubah oleh JavaScript. Dalam aplikasi ini, ilusi arsitektur halaman web konvensional dipertahankan dengan mengubah URL dan mendorong URL sebelumnya dalam histori browser untuk memungkinkan 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 secara tradisional dipahami browser sebagai "halaman", pengukuran ini selalu sulit dilakukan: di mana batas yang harus ditarik antara interaksi di halaman saat ini, dibandingkan dengan menganggapnya sebagai halaman baru?

Tim Chrome telah mempertimbangkan tantangan ini selama beberapa waktu, dan berupaya menstandardisasi definisi "navigasi ringan", serta cara mengukur Data Web Inti untuk hal ini—dengan cara yang serupa dengan cara situs yang diterapkan dalam arsitektur multi-halaman (MPA) konvensional diukur.

Kami telah berupaya keras meningkatkan kualitas API sejak uji coba origin terakhir dan kini meminta developer untuk mencoba iterasi terbaru dan memberikan masukan tentang pendekatan ini sebelum diluncurkan.

Apa itu navigasi lembut?

Kami telah membuat definisi navigasi ringan berikut:

• Navigasi dimulai oleh tindakan pengguna.
• Navigasi menghasilkan perubahan URL yang terlihat oleh pengguna, dan perubahan histori.
• Navigasi menghasilkan perubahan DOM.

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

Bagaimana Chrome menerapkan navigasi ringan?

Setelah heuristik navigasi ringan diaktifkan (selengkapnya tentang hal ini di bagian berikutnya), Chrome akan mengubah cara pelaporan beberapa metrik performa:

• Peristiwa soft-navigation PerformanceTiming akan dipancarkan setelah setiap navigasi ringan terdeteksi.
• interaction-contentful-paint baru akan dikeluarkan setelah interaksi yang menyebabkan paint yang bermakna. Hal ini dapat digunakan untuk mengukur Largest Contentful Paint (LCP) untuk navigasi ringan saat paint tersebut mencakup navigasi ringan. Perhatikan bahwa penerapan awal reset ini akan mereset metrik largest-contentful-paint sehingga dapat dipancarkan kembali, tetapi kami telah memutuskan pendekatan alternatif ini untuk kesederhanaan dan juga cakupan masa depan yang lebih luas.
• Atribut navigationId akan ditambahkan ke setiap waktu performa (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event, dan layout-shift) yang sesuai dengan entri navigasi yang terkait dengan peristiwa tersebut, sehingga Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), dan Interaction to Next Paint (INP) dapat dihitung dan diatribusikan ke URL yang benar.

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

Apa implikasi mengaktifkan navigasi ringan di Chrome?

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

• Metrik CLS dan INP dapat dikelompokkan berdasarkan URL navigasi ringan, bukan diukur selama durasi siklus proses seluruh halaman.
• Entri largest-contentul-paint sudah difinalisasi pada interaksi, sehingga hanya digunakan untuk mengukur LCP navigasi "berat" awal, sehingga tidak ada logika tambahan yang diperlukan untuk mengubah cara pengukurannya.
• Metrik interaction-contentful-paint baru akan dikeluarkan dari interaksi, yang dapat digunakan untuk mengukur LCP untuk navigasi ringan.
• Untuk mengatribusikan navigasi ringan ke URL yang benar, atribut navigationID baru pada entri performa Anda mungkin perlu dipertimbangkan dalam kode aplikasi menggunakan entri ini.
• Tidak semua pengguna akan mendukung API navigasi ringan ini, terutama untuk Chrome versi lama, dan bagi mereka yang menggunakan browser lain. Perlu diketahui bahwa beberapa pengguna mungkin tidak melaporkan metrik navigasi ringan, meskipun mereka melaporkan metrik Core Web Vitals.
• Sebagai fitur baru eksperimental yang tidak diaktifkan secara default, situs harus menguji fitur ini untuk mengetahui efek samping yang tidak diinginkan.

Tanyakan kepada penyedia RUM Anda apakah mereka mendukung pengukuran Data Web Inti dengan navigasi ringan. Banyak yang berencana menguji standar baru ini, dan akan mempertimbangkan pertimbangan sebelumnya. Sementara itu, beberapa penyedia juga mengizinkan pengukuran terbatas 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?

Navigasi ringan tidak diaktifkan secara default di Chrome, tetapi tersedia untuk eksperimen dengan mengaktifkan fitur ini secara eksplisit.

Untuk developer, fitur ini dapat diaktifkan dengan mengaktifkan tanda di chrome://flags/#soft-navigation-heuristics. Opsi "Aktifkan Atribusi Paint Lanjutan (Eager Cached Pre-Paint Walk)" adalah opsi yang direkomendasikan dan akan segera menjadi opsi default. Atau, fitur ini dapat diaktifkan menggunakan argumen command line --enable-features=SoftNavigationHeuristics:mode/advanced_paint_attribution saat meluncurkan Chrome.

Untuk situs yang ingin mengaktifkan fitur ini agar semua pengunjungnya dapat melihat dampaknya, akan ada uji coba asal yang berjalan dari Chrome 139 yang dapat diaktifkan dengan mendaftar ke uji coba dan menyertakan elemen meta dengan token uji coba asal di header HTML atau HTTP. Lihat postingan Memulai uji coba origin untuk mengetahui informasi selengkapnya.

Pemilik situs dapat memilih untuk menyertakan uji coba origin di halaman mereka untuk semua pengguna, atau hanya untuk sebagian pengguna. Perhatikan bagian implikasi sebelumnya mengenai bagaimana perubahan ini dapat memengaruhi cara pelaporan metrik Anda, terutama jika Anda mengaktifkan uji coba origin ini untuk sebagian besar pengguna Anda. Perhatikan bahwa CrUX akan terus melaporkan metrik dengan cara yang ada, terlepas dari setelan navigasi ringan ini, sehingga tidak terpengaruh oleh implikasi tersebut. Perlu juga diperhatikan bahwa uji coba origin juga terbatas untuk mengaktifkan fitur eksperimental pada maksimum 0,5% dari semua pemuatan halaman Chrome sebagai median selama 14 hari, tetapi hal ini hanya akan menjadi masalah bagi situs yang sangat besar.

Bagaimana cara mengukur navigasi sementara?

Setelah eksperimen navigasi lembut diaktifkan, metrik akan dilaporkan menggunakan PerformanceObserver API seperti metrik lainnya. Namun, ada beberapa pertimbangan tambahan yang perlu diperhitungkan untuk metrik ini.

Melaporkan navigasi ringan

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

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

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

Melaporkan metrik terhadap URL yang sesuai

Karena navigasi ringan hanya dapat dilihat setelah terjadi, beberapa metrik harus diselesaikan setelah peristiwa ini, lalu dilaporkan untuk URL sebelumnya, karena URL saat ini akan mencerminkan URL yang diperbarui untuk halaman baru.

Atribut navigationId dari PerformanceEntry yang sesuai dapat digunakan untuk mengaitkan kembali peristiwa ke URL yang benar. Hal ini dapat dicari dengan PerformanceEntry API:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

pageUrl ini harus digunakan untuk melaporkan metrik terhadap URL yang benar, bukan URL saat ini yang mungkin telah mereka gunakan di masa lalu.

Mendapatkan startTime navigasi ringan

Waktu mulai navigasi dapat diperoleh dengan cara yang serupa:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

startTime adalah waktu interaksi awal (misalnya, klik tombol) yang memulai navigasi sementara.

Semua pengaturan waktu performa, termasuk untuk navigasi ringan, dilaporkan sebagai waktu dari waktu navigasi halaman "berat" awal. Oleh karena itu, waktu mulai navigasi ringan diperlukan untuk membandingkan waktu metrik pemuatan navigasi ringan (misalnya LCP), relatif terhadap waktu navigasi ringan ini.

Mengukur Data Web Inti per navigasi ringan

Untuk menyertakan entri metrik navigasi lembut, Anda harus menyertakan includeSoftNavigationObservations: true dalam panggilan observe pengamat performa.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

Dengan perubahan terbaru pada API, tanda includeSoftNavigationObservations tidak lagi diperlukan dan kemungkinan akan dihapus pada masa mendatang, tetapi untuk saat ini, keikutsertaan eksplisit di tingkat pengamat performa ini diperlukan selain mengaktifkan fitur navigasi ringan di Chrome.

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

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'interaction-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

Beberapa metrik secara tradisional diukur selama masa aktif halaman: LCP, misalnya, dapat berubah hingga interaksi terjadi. CLS dan INP dapat diperbarui hingga pengguna keluar dari halaman. Oleh karena itu, setiap "navigasi" (termasuk navigasi asli) mungkin perlu menyelesaikan metrik halaman sebelumnya saat setiap navigasi ringan baru terjadi. Artinya, metrik navigasi "berat" awal dapat diselesaikan lebih awal dari biasanya.

Demikian pula, saat mulai mengukur metrik untuk navigasi ringan baru dari metrik yang berjalan lama ini, metrik harus "direset" atau "diinisialisasi ulang" dan diperlakukan sebagai metrik baru, tanpa mengingat nilai yang ditetapkan untuk "halaman" sebelumnya.

Bagaimana seharusnya konten yang tetap sama di antara navigasi ditangani?

LCP untuk navigasi ringan (dihitung dari interaction-contentful-paint) hanya akan mengukur paint baru. Hal ini dapat menghasilkan LCP yang berbeda, misalnya, dari pemuatan dingin navigasi ringan tersebut ke pemuatan ringan.

Misalnya, ambil halaman yang menyertakan gambar banner besar yang merupakan elemen LCP, tetapi teks di bawahnya berubah dengan setiap navigasi ringan. Pemuatan halaman awal akan menandai gambar banner sebagai elemen LCP dan mendasarkan waktu LCP pada gambar tersebut. Untuk navigasi ringan berikutnya, teks di bawahnya akan menjadi elemen terbesar yang digambar setelah navigasi ringan dan akan menjadi elemen LCP baru. Namun, jika halaman baru dimuat dengan deep link ke URL navigasi ringan, gambar banner akan menjadi gambar baru dan oleh karena itu akan memenuhi syarat untuk dianggap sebagai elemen LCP.

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.

Bagaimana cara mengukur TTFB?

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

Untuk navigasi sementara, 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 sebelumnya? Bagaimana jika permintaan tidak terkait dengan navigasi ringan dari perspektif pengguna (misalnya, permintaan analisis)?

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

Pada masa mendatang, kami dapat mendukung cara yang lebih tepat untuk mengetahui permintaan mana yang merupakan "permintaan navigasi" navigasi ringan dan akan dapat melakukan pengukuran TTFB yang lebih tepat. Namun, hal itu bukan bagian dari penerapan saat ini.

Bagaimana cara mengukur versi lama dan baru?

Selama eksperimen ini, sebaiknya terus ukur Data Web Inti Anda dengan cara saat ini, berdasarkan navigasi halaman "keras" agar sesuai dengan yang akan diukur dan dilaporkan oleh CrUX sebagai set data resmi inisiatif Data Web Inti.

Navigasi ringan harus diukur selain navigasi berat agar Anda dapat melihat cara pengukuran navigasi ringan di masa mendatang, dan memberi Anda kesempatan untuk memberikan masukan kepada tim Chrome tentang cara kerja implementasi ini dalam praktiknya. Hal ini akan membantu Anda dan tim Chrome membentuk API ke depannya.

Untuk LCP, hal ini berarti hanya mempertimbangkan entri largest-contentful-paint untuk cara lama, 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 pada cara lama, dan membagi linimasa secara terpisah menurut navigasi ringan untuk mengukur nilai CLS dan INP yang terpisah untuk cara baru.

Gunakan library web-vitals untuk mengukur Data Web Inti untuk navigasi ringan

Cara termudah untuk memperhitungkan semua nuansa adalah dengan menggunakan library JavaScript web-vitals yang memiliki dukungan eksperimental untuk navigasi ringan dalam soft-navs branch terpisah (yang juga tersedia di npm dan unpkg). Hal ini dapat diukur dengan cara berikut (ganti doTraditionalProcessing dan doSoftNavProcessing sesuai kebutuhan):

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

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});

Pastikan metrik dilaporkan terhadap URL yang benar seperti yang disebutkan sebelumnya.

Library web-vitals melaporkan metrik berikut untuk navigasi ringan:

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

Eksperimen navigasi ringan ini persis seperti itu—sebuah eksperimen. Kami ingin mengevaluasi heuristik dan melihat apakah heuristik tersebut lebih akurat mencerminkan pengalaman pengguna sebelum kami membuat keputusan apakah heuristik ini akan diintegrasikan dalam inisiatif Core Web Vitals. Kami sangat antusias dengan kemungkinan eksperimen ini, tetapi tidak dapat memberikan jaminan apakah atau kapan eksperimen ini akan menggantikan pengukuran saat ini.

Kami menghargai masukan developer web tentang eksperimen, heuristik yang digunakan, dan apakah Anda merasa heuristik tersebut lebih akurat dalam mencerminkan pengalaman. Repositori GitHub navigasi lembut adalah tempat terbaik untuk memberikan masukan tersebut, meskipun bug individual dengan penerapan Chrome harus dilaporkan di pelacak masalah Chrome.

Bagaimana navigasi ringan akan dilaporkan di CrUX?

Cara tepat pelaporan navigasi lembut di CrUX, jika eksperimen ini berhasil, juga masih harus ditentukan. Belum tentu mereka akan diperlakukan sama seperti navigasi "hard" saat ini.

Di beberapa halaman web, navigasi ringan hampir identik dengan pemuatan halaman penuh sejauh yang dirasakan pengguna dan penggunaan teknologi Aplikasi Web Satu Halaman hanyalah detail penerapan. Di tempat lain, mungkin lebih mirip dengan pemuatan sebagian konten tambahan.

Oleh karena itu, kami dapat memutuskan untuk melaporkan navigasi ringan ini secara terpisah di CrUX, atau mungkin memberi bobot saat menghitung Data Web Inti untuk halaman atau grup halaman tertentu. Kita juga dapat mengecualikan sepenuhnya navigasi lembut pemuatan parsial, seiring berkembangnya heuristik.

Tim sedang berkonsentrasi pada penerapan heuristik dan teknis, yang akan memungkinkan kami menilai keberhasilan eksperimen ini, sehingga belum ada keputusan yang dibuat terkait hal ini.

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.

Log perubahan

Karena API ini dalam tahap eksperimen, sejumlah perubahan terjadi padanya, lebih banyak daripada API stabil. Anda dapat melihat Log Perubahan Heuristik Navigasi Lembut untuk mengetahui detail selengkapnya.

Kesimpulan

Eksperimen navigasi ringan adalah pendekatan menarik tentang bagaimana inisiatif Core Web Vitals dapat berkembang untuk mengukur pola umum di web modern yang tidak ada dalam metrik kami. Meskipun eksperimen ini masih dalam tahap awal—dan masih banyak yang harus dilakukan—membuat progres yang telah dicapai sejauh ini tersedia bagi komunitas web yang lebih luas untuk bereksperimen adalah langkah penting. Mengumpulkan masukan dari eksperimen ini adalah bagian penting lainnya dari eksperimen ini. Jadi, kami sangat menganjurkan agar pihak yang tertarik dengan pengembangan ini menggunakan kesempatan ini untuk membantu membentuk API guna memastikan API ini mewakili apa yang ingin kami ukur dengan 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 ia masih bekerja di Google. Kami berterima kasih kepada Yoav atas upayanya dalam mengembangkan API ini.