Bereksperimen dengan pengukuran navigasi ringan

Barry Pollard

Yoav Weiss

Sejak diluncurkan, inisiatif Data Web Inti berupaya mengukur pengalaman pengguna yang sebenarnya pada situs, dan bukan detail teknis di balik cara situs dibuat atau dimuat. Tiga metrik Data Web Inti dibuat sebagai metrik yang berfokus pada pengguna—sebuah evolusi dibandingkan metrik teknis yang ada sepertiDOMContentLoaded atau load yang mengukur waktu yang sering kali tidak terkait dengan persepsi pengguna terhadap performa halaman. Karena itu, teknologi yang digunakan untuk membuat situs tidak boleh memengaruhi penskoran karena situs tersebut memiliki performa yang baik.

Kenyataannya selalu sedikit lebih rumit daripada yang ideal, dan arsitektur Aplikasi Web Satu Halaman yang populer tidak pernah sepenuhnya didukung oleh metrik Data Web Inti. Alih-alih memuat halaman web individual yang berbeda saat pengguna menavigasi situs, aplikasi web ini menggunakan apa yang disebut "navigasi lunak", dengan konten laman diubah oleh JavaScript. Dalam aplikasi ini, ilusi arsitektur halaman web konvensional dipertahankan dengan mengubah URL dan mendorong URL sebelumnya di 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 di luar apa yang biasanya dipahami browser sebagai "halaman", pengukuran ini selalu sulit: di mana batas yang harus digambar antara interaksi pada halaman saat ini, dibandingkan menganggap ini sebagai halaman baru?

Tim Chrome telah mempertimbangkan tantangan ini sejak lama, dan ingin menstandarkan definisi apa yang dimaksud dengan "navigasi lunak", dan cara Data Web Inti dapat diukur untuk hal ini—dengan cara yang sama seperti pengukuran situs yang diterapkan dalam arsitektur multi-halaman (MPA) konvensional. Meskipun masih dalam tahap awal, tim kini siap membuat apa yang telah diimplementasikan secara lebih luas agar situs dapat bereksperimen. Hal ini akan memungkinkan situs memberikan masukan tentang pendekatan sejauh ini.

Apa itu navigasi lunak?

Kami telah menemukan definisi navigasi ringan berikut:

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

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

Bagaimana cara Chrome menerapkan navigasi virtual?

Setelah heuristik navigasi virtual diaktifkan (informasi selengkapnya di bagian berikutnya), Chrome akan mengubah cara pelaporan beberapa metrik performa:

• Peristiwa PerformanceTiming soft-navigation akan ditampilkan setelah setiap navigasi virtual terdeteksi.
• API performa akan memberikan akses ke entri waktu soft-navigation, seperti yang dimunculkan oleh peristiwa soft-navigation PerformanceTiming.
• Metrik First Paint (FP), First Contentful Paint (FCP), Largest Contentful Paint (LCP) akan direset, dan dimunculkan ulang pada kejadian berikutnya yang sesuai. (Catatan: FP dan FCP belum diterapkan.)
• Atribut navigationId akan ditambahkan ke setiap waktu performa (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event, dan layout-shift) yang sesuai dengan entri navigasi yang terkait dengan peristiwa tersebut, sehingga Pergeseran Tata Letak Kumulatif (CLS) dan Interaction to Next Paint (INP) dapat dihitung.

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

Apa saja implikasi dari mengaktifkan navigasi virtual di Chrome?

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

• Peristiwa FP, FCP, dan LCP tambahan dapat dimunculkan ulang untuk navigasi ringan. Laporan Pengalaman Pengguna Chrome (CrUX) akan mengabaikan nilai tambahan ini, tetapi dapat memengaruhi pemantauan Pengukuran Pengguna Asli (RUM) di situs Anda. Hubungi penyedia RUM jika Anda memiliki masalah apakah hal ini akan memengaruhi pengukuran tersebut. Lihat bagian tentang mengukur Data Web Inti untuk navigasi ringan.
• Atribut navigationID baru (dan opsional) pada entri performa Anda mungkin perlu dipertimbangkan dalam kode aplikasi menggunakan entri ini.
• Hanya browser berbasis Chromium yang akan mendukung mode baru ini. Meskipun banyak metrik baru hanya tersedia di browser berbasis Chromium, beberapa metrik (FCP, LCP) tersedia di browser lain, dan tidak semua orang mungkin telah mengupgrade ke browser berbasis Chromium versi terbaru. Jadi perlu diketahui bahwa beberapa pengguna mungkin tidak melaporkan metrik navigasi virtual.
• Sebagai fitur baru eksperimental yang tidak diaktifkan secara default, situs harus menguji fitur ini untuk memastikan tidak ada efek samping yang tidak diinginkan lainnya.

Untuk informasi selengkapnya tentang cara mengukur metrik untuk navigasi virtual, lihat bagian Mengukur Data Web Inti per navigasi virtual.

Bagaimana cara mengaktifkan navigasi virtual di Chrome?

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

Untuk developer, setelan ini dapat diaktifkan dengan mengaktifkan tanda Fitur Platform Web Eksperimental di chrome://flags/#enable-experimental-web-platform-features atau dengan menggunakan argumen command line --enable-experimental-web-platform-features saat meluncurkan Chrome.

Bagi situs yang ingin mengaktifkan fitur ini bagi semua pengunjungnya agar dapat melihat dampaknya, ada uji coba origin yang dijalankan dari Chrome 117 yang dapat diaktifkan dengan mendaftar ke uji coba dan menyertakan elemen meta dengan token uji coba origin di header HTML atau HTTP. Lihat postingan Mulai menggunakan 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 tentang bagaimana hal ini mengubah cara pelaporan metrik Anda, terutama jika mengaktifkan uji coba origin ini untuk sebagian besar pengguna Anda. Perhatikan bahwa CrUX akan terus melaporkan metrik dengan cara yang sudah ada, terlepas dari setelan navigasi ringan ini, sehingga tidak terpengaruh oleh implikasi tersebut. Perlu diperhatikan juga bahwa uji coba origin juga dibatasi pada pengaktifan fitur eksperimental 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 lunak?

Setelah eksperimen navigasi virtual diaktifkan, metrik akan dilaporkan menggunakan PerformanceObserver API seperti biasa. 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 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 aktif penuh untuk navigasi sebelumnya.

Melaporkan metrik berdasarkan URL yang sesuai

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

Atribut navigationId dari PerformanceEntry yang sesuai dapat digunakan untuk mengaitkan peristiwa kembali ke URL yang benar. 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 digunakan di masa lalu.

Mendapatkan startTime navigasi ringan

Waktu mulai navigasi bisa diperoleh dengan cara yang sama:

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 virtual.

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

Mengukur Data Web Inti per navigasi ringan

Untuk menyertakan entri metrik navigasi virtual, Anda harus menyertakan includeSoftNavigationObservations: true dalam panggilan observe performance observer Anda.

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

Tanda includeSoftNavigationObservations tambahan pada metode observe diperlukan selain mengaktifkan fitur navigasi virtual di Chrome. Keikutsertaan eksplisit di tingkat pengamat performa ini adalah untuk memastikan pengamat performa yang ada tidak terkejut dengan entri tambahan ini karena beberapa pertimbangan tambahan perlu diperhitungkan saat mencoba mengukur Data Web Inti untuk navigasi ringan.

Waktu akan tetap ditampilkan sehubungan dengan waktu mulai navigasi "sulit" yang asli. Jadi, misalnya untuk menghitung LCP untuk navigasi ringan, Anda perlu mengambil pengaturan waktu LCP dan mengurangi waktu mulai navigasi lunak yang sesuai seperti yang telah diperinci sebelumnya untuk mendapatkan pengaturan waktu yang relatif terhadap navigasi lunak. 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: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

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

Demikian pula, saat mulai mengukur metrik untuk navigasi sementara baru dari metrik berumur panjang ini, metrik harus "direset" atau "diinisialisasi ulang" dan diperlakukan sebagai metrik baru, tanpa memori nilai yang ditetapkan untuk "halaman" sebelumnya.

Bagaimana seharusnya konten yang tetap sama di antara navigasi diperlakukan?

FP, FCP, dan LCP untuk navigasi lunak hanya akan mengukur paint baru. Hal ini dapat mengakibatkan LCP yang berbeda, misalnya, dari cold load navigasi ringan hingga soft load.

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

Seperti yang ditunjukkan dalam contoh ini, elemen LCP untuk navigasi sementara dapat dilaporkan secara berbeda, bergantung pada cara halaman dimuat—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 dari permintaan asli ditampilkan.

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

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

Di masa mendatang, kami dapat mendukung cara yang lebih tepat untuk mengetahui permintaan mana yang merupakan "permintaan navigasi" navigasi ringan dan akan dapat memberikan pengukuran TTFB yang lebih tepat. Namun, hal tersebut bukan bagian dari eksperimen saat ini.

Bagaimana cara mengukur data lama dan baru?

Selama eksperimen ini, sebaiknya terus pengukuran Core Web Vitals Anda dengan cara saat ini, berdasarkan navigasi halaman "hard" agar sesuai dengan data yang akan diukur dan dilaporkan oleh CrUX sebagai set data resmi inisiatif Core Web Vitals.

Selain itu, navigasi ringan harus diukur selain alat ini agar Anda dapat melihat cara pengukurannya di masa mendatang, dan memberi Anda kesempatan untuk memberikan masukan kepada tim Chrome tentang cara kerja implementasi ini. Hal ini akan membantu Anda dan tim Chrome untuk membentuk API ke depannya.

Untuk mengukur keduanya, Anda harus mengetahui peristiwa baru yang mungkin dikeluarkan saat dalam mode navigasi lunak (misalnya, beberapa peristiwa FCP dan LCP tambahan) dan menanganinya secara tepat dengan menyelesaikan metrik ini pada waktu yang tepat, sekaligus mengabaikan peristiwa mendatang yang hanya berlaku untuk navigasi ringan.

Menggunakan library web-vitals guna mengukur Data Web Inti untuk navigasi ringan

Cara termudah untuk memperhitungkan semua perbedaan adalah dengan menggunakan library JavaScript web-vitals yang memiliki dukungan eksperimental untuk navigasi ringan di soft-navs branch terpisah (yang juga tersedia di npm dan unpkg). Hal ini dapat diukur dengan cara berikut (mengganti 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 dengan URL yang benar seperti yang disebutkan sebelumnya.

Library web-vitals melaporkan metrik berikut untuk navigasi virtual:

Apakah perubahan ini akan menjadi bagian dari pengukuran Data Web Inti?

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

Kami menghargai masukan developer web mengenai eksperimen, heuristik yang digunakan, dan apakah Anda merasa pengalaman tersebut lebih akurat mencerminkan pengalaman. Repositori GitHub navigasi virtual adalah tempat terbaik untuk memberikan masukan tersebut, meskipun bug individual dengan implementasi Chrome harus dilaporkan di Issue Tracker Chrome.

Bagaimana navigasi lunak akan dilaporkan di CrUX?

Bagaimana tepatnya navigasi ringan akan dilaporkan di CrUX, jika eksperimen ini berhasil, juga masih ditentukan. Hal ini belum tentu karena navigasi tersebut akan diperlakukan sama seperti navigasi "hard" saat ini yang diperlakukan.

Di beberapa halaman web, navigasi ringan hampir identik dengan pemuatan halaman penuh sejauh yang diperhatikan pengguna dan penggunaan teknologi Aplikasi Web Satu Halaman hanyalah detail implementasi. Di sisi lain, setelan ini 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 menimbangnya saat menghitung Data Web Inti untuk halaman atau grup halaman tertentu. Kami juga dapat mengecualikan sepenuhnya navigasi ringan pemuatan sebagian, seiring dengan berkembangnya heuristik.

Saat ini, tim kami sedang berkonsentrasi pada implementasi heuristik dan teknis, yang akan memungkinkan kami menilai keberhasilan eksperimen ini, sehingga tidak ada keputusan yang diambil terkait aspek ini.

Masukan

Kami mencari masukan secara aktif terkait eksperimen ini di tempat-tempat berikut:

• Heuristik dan standardisasi navigasi ringan.
• Masalah implementasi Chrome pada heuristik tersebut.
• Masukan data web umum di web-vitals-feedback@googlegrouops.com.

Log perubahan

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

Kesimpulan

Eksperimen navigasi ringan adalah pendekatan yang menarik tentang bagaimana inisiatif Data Web Inti dapat berkembang untuk mengukur pola umum di web modern yang saat ini hilang dari metrik kami. Meskipun eksperimen ini masih dalam tahap awal—dan masih banyak yang harus dilakukan—membuat progres sejauh ini dapat dicoba oleh komunitas web yang lebih luas adalah langkah yang penting. Mengumpulkan masukan dari eksperimen ini merupakan bagian penting lain dari eksperimen ini, jadi kami sangat mendorong mereka yang tertarik dengan pengembangan ini untuk menggunakan kesempatan ini guna membantu membentuk API guna memastikannya mewakili apa yang kami harapkan dapat diukur dengan hal ini.

Ucapan terima kasih

Gambar thumbnail oleh Jordan Madrid di Unsplash