Bereksperimen dengan pengukuran navigasi ringan

Barry Pollard

Yoav Weiss

Sejak diluncurkan, inisiatif Core Web Vitals telah berupaya mengukur pengalaman pengguna yang sebenarnya dari suatu situs, bukan detail teknis terkait cara pembuatan atau pemuatan situs. Ketiga metrik Core Web Vitals 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. Oleh karena itu, teknologi yang digunakan untuk membuat situs seharusnya tidak memengaruhi penskoran yang menyediakan situs bekerja dengan baik.

Kenyataannya selalu sedikit lebih rumit dari yang ideal, dan arsitektur Aplikasi Web Satu Halaman yang populer tidak pernah sepenuhnya didukung oleh metrik Core Web Vitals. Aplikasi web ini menggunakan apa yang disebut "navigasi ringan", yang alih-alih memuat halaman web individual yang berbeda saat pengguna menavigasi situs, aplikasi web ini menggunakan apa yang disebut "navigasi ringan", yang mana konten halaman justru diubah oleh JavaScript. Dalam aplikasi ini, ilusi arsitektur laman web konvensional dipertahankan dengan mengubah URL dan mendorong URL sebelumnya dalam riwayat browser untuk memungkinkan tombol kembali dan maju berfungsi seperti yang diharapkan pengguna.

Banyak framework JavaScript menggunakan model ini, tetapi masing-masing dengan cara berbeda. Karena hal ini di luar pemahaman browser secara tradisional sebagai "halaman", mengukurnya menjadi sulit: di mana garis yang harus digambar di antara interaksi pada halaman saat ini, dibandingkan dengan menganggapnya sebagai halaman baru?

Tim Chrome telah mempertimbangkan tantangan ini selama beberapa waktu dan sedang berupaya menstandarkan definisi tentang apa yang dimaksud dengan "navigasi ringan", dan cara pengukuran Data Web Inti untuk hal ini—dengan cara yang sama seperti pengukuran yang diterapkan situs di arsitektur multi-halaman (MPA) konvensional. Meskipun masih dalam tahap awal, tim kini siap untuk memperluas ketersediaan implementasi yang telah diterapkan ke berbagai situs untuk bereksperimen. Dengan begitu, situs dapat memberikan masukan terkait pendekatan yang telah dilakukan sejauh ini.

Apa itu navigasi lunak?

Kami telah menemukan definisi navigasi ringan berikut:

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

Untuk beberapa situs, heuristik ini dapat mengarah pada positif palsu (bahwa pengguna tidak benar-benar menganggap "navigasi" pernah terjadi) atau negatif palsu (ketika pengguna menganggap "navigasi" telah terjadi meskipun tidak memenuhi kriteria ini). Kami menyambut baik masukan di repositori spesifikasi navigasi ringan terkait heuristik.

Bagaimana cara Chrome menerapkan navigasi virtual?

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

• Peristiwa soft-navigation PerformanceTiming akan dikeluarkan setelah setiap navigasi virtual terdeteksi.
• Performance API 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 ditampilkan kembali pada kejadian yang tepat berikutnya. (Catatan: FP dan FCP tidak diterapkan.)
• Atribut navigationId akan ditambahkan ke setiap pengaturan 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 Core Web Vitals—dan beberapa metrik diagnostik terkait—diukur per navigasi halaman, meskipun ada beberapa hal yang perlu dipertimbangkan.

Apa implikasi pengaktifan navigasi yang lembut di Chrome?

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

• Peristiwa FP, FCP, dan LCP tambahan dapat ditampilkan kembali untuk navigasi virtual. Chrome User Experience Report (CrUX) akan mengabaikan nilai tambahan ini, tetapi hal ini dapat memengaruhi pemantauan Pengukuran Pengguna Nyata (RUM) di situs Anda. Hubungi penyedia RUM jika Anda memiliki kekhawatiran jika hal ini akan memengaruhi pengukuran tersebut. Lihat bagian tentang mengukur Core Web Vitals untuk navigasi ringan.
• Atribut navigationID baru (dan opsional) pada entri performa Anda mungkin perlu dipertimbangkan dalam kode aplikasi Anda menggunakan entri ini.
• Hanya browser berbasis Chromium yang akan mendukung mode baru ini. Meskipun banyak dari metrik baru ini 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. Perhatikan bahwa beberapa pengguna mungkin tidak melaporkan metrik navigasi virtual.
• Sebagai fitur eksperimental baru yang tidak diaktifkan secara default, situs harus menguji fitur ini untuk memastikan tidak ada efek samping lain yang tidak diinginkan.

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

Bagaimana cara mengaktifkan navigasi lunak di Chrome?

Navigasi lunak 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 Fitur Web Platform Eksperimental di chrome://flags/#enable-experimental-web-platform-features atau dengan menggunakan argumen command line --enable-experimental-web-platform-features saat meluncurkan Chrome.

Bagaimana cara mengukur navigasi virtual?

Setelah eksperimen navigasi ringan diaktifkan, metrik akan melaporkan menggunakan PerformanceObserver API seperti biasa. Namun, ada beberapa pertimbangan tambahan yang harus diperhitungkan untuk metrik ini.

Melaporkan navigasi ringan

Anda dapat menggunakan PerformanceObserver untuk mengamati navigasi virtual. Berikut adalah contoh cuplikan kode yang mencatat entri navigasi virtual ke konsol—termasuk navigasi virtual 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 sepanjang waktu untuk navigasi sebelumnya.

Melaporkan metrik terhadap URL yang sesuai

Karena navigasi sementara hanya dapat dilihat setelah peristiwa tersebut 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 peristiwa kembali 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 digunakan sebelumnya.

Mendapatkan startTime navigasi opsional

Waktu mulai navigasi dapat 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 untuk navigasi lunak, dilaporkan sebagai waktu dari "sulit" awal waktu navigasi halaman. Oleh karena itu, waktu mulai navigasi lunak diperlukan untuk membuat dasar waktu metrik pemuatan navigasi lunak (misalnya LCP), relatif terhadap waktu navigasi opsional ini.

Mengukur Core Web Vitals per navigasi lunak

Untuk menyertakan entri metrik navigasi ringan, 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});

Flag includeSoftNavigationObservations tambahan di metode observe diperlukan selain mengaktifkan fitur navigasi sementara di Chrome. Keikutsertaan eksplisit di tingkat observer performa ini bertujuan untuk memastikan bahwa observer performa yang ada tidak dikejutkan dengan entri tambahan ini, karena beberapa pertimbangan tambahan perlu diperhitungkan saat mencoba mengukur Core Web Vitals untuk navigasi ringan.

Waktu akan tetap ditampilkan sehubungan dengan "sulit" asli waktu mulai navigasi. Jadi, misalnya, untuk menghitung LCP untuk navigasi ringan, Anda perlu mengambil pengaturan waktu LCP dan mengurangi waktu mulai navigasi lunak yang sesuai seperti yang diuraikan sebelumnya untuk mendapatkan pengaturan waktu yang terkait dengan navigasi sementara. 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 halaman: Misalnya, LCP dapat berubah hingga terjadi interaksi. CLS dan INP dapat diperbarui hingga halaman dihapus. Oleh karena itu, setiap "navigasi" (termasuk navigasi asli) mungkin perlu menyelesaikan metrik halaman sebelumnya karena setiap navigasi virtual baru muncul. Ini berarti "hard" awal metrik navigasi dapat diselesaikan lebih awal seperti biasa.

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

Bagaimana konten yang tetap sama di antara navigasi harus diperlakukan?

FP, FCP, dan LCP untuk navigasi ringan hanya akan mengukur cat baru. Hal ini dapat menghasilkan LCP yang berbeda, misalnya, dari pemuatan cold navigasi lunak tersebut ke pemuatan ringan.

Misalnya, ambil halaman yang menyertakan gambar banner besar yang merupakan elemen LCP, tetapi teks di bawahnya berubah dengan setiap navigasi virtual. Pemuatan halaman awal akan menandai gambar banner sebagai elemen LCP dan mendasarkan waktu LCP pada hal tersebut. Untuk navigasi lunak berikutnya, teks di bawahnya akan menjadi elemen terbesar yang digambar setelah navigasi virtual dan akan menjadi elemen LCP baru. Namun, jika halaman baru dimuat dengan deep link ke URL navigasi virtual, gambar banner akan menjadi gambar baru sehingga 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 dari permintaan asli ditampilkan.

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

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

Di masa mendatang, kami mungkin mendukung cara yang lebih tepat untuk mengetahui permintaan mana yang merupakan "permintaan navigasi" navigasi virtual dan akan dapat memiliki pengukuran TTFB yang lebih tepat. Namun, itu bukan bagian dari eksperimen saat ini.

Bagaimana cara mengukur performa lama dan baru?

Selama eksperimen ini, sebaiknya terus ukur Core Web Vitals Anda dengan cara saat ini, berdasarkan skor "kesulitan" navigasi halaman untuk mencocokkan dengan apa yang akan diukur dan dilaporkan CrUX sebagai set data resmi dari inisiatif Core Web Vitals.

Selain fitur-fitur tersebut, navigasi lunak harus diukur untuk memungkinkan Anda 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 dalam membentuk API ke depannya.

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

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

Cara termudah untuk mempertimbangkan semua nuansa tersebut 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 yang sesuai):

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 berdasarkan URL yang benar seperti yang disebutkan sebelumnya.

Library web-vitals melaporkan metrik berikut untuk navigasi sementara:

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

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

Kami menghargai upaya para developer web masukan tentang eksperimen, heuristik yang digunakan, dan apakah Anda merasa eksperimen mencerminkan pengalaman dengan lebih akurat. Repositori GitHub navigasi ringan adalah tempat terbaik untuk memberikan masukan tersebut, meskipun setiap bug terkait implementasi Chrome harus disebutkan dalam Issue Tracker Chrome.

Bagaimana navigasi lunak akan dilaporkan di CrUX?

Bagaimana tepatnya navigasi lunak akan dilaporkan di CrUX, apakah eksperimen ini berhasil, juga masih harus ditentukan. Tidak berarti bahwa nilai tersebut akan diperlakukan sama dengan "hard" (hard) saat ini navigasi akan diperlakukan.

Di beberapa halaman web, navigasi lunak hampir identik dengan pemuatan halaman penuh sejauh yang diperhatikan pengguna dan penggunaan teknologi Aplikasi Web Satu Halaman hanyalah detail implementasi. Sementara itu, sebagian lainnya mungkin lebih mirip dengan pemuatan sebagian konten tambahan.

Oleh karena itu, kami dapat memutuskan untuk melaporkan navigasi lunak ini secara terpisah di CrUX, atau mungkin menimbangnya saat menghitung Core Web Vitals untuk halaman atau grup halaman tertentu. Kami mungkin juga dapat sepenuhnya mengecualikan navigasi lunak pemuatan parsial, seiring berkembangnya heuristik.

Tim ini berkonsentrasi pada penerapan heuristik dan teknis, yang akan memungkinkan kami menilai keberhasilan eksperimen ini, jadi tidak ada keputusan yang dibuat untuk bidang ini.

Masukan

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

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

Log perubahan

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

Kesimpulan

Eksperimen navigasi ringan adalah pendekatan yang menarik terhadap bagaimana inisiatif Core Web Vitals dapat berkembang untuk mengukur pola umum di web modern yang hilang dari metrik kami. Meskipun eksperimen ini masih dalam tahap awal—dan masih banyak yang harus dilakukan—membuat progres yang tersedia sejauh ini untuk komunitas web yang lebih luas untuk bereksperimen merupakan langkah penting. Mengumpulkan masukan dari eksperimen ini merupakan bagian penting lain dari eksperimen, jadi kami sangat mendorong pengguna yang tertarik dengan pengembangan ini untuk menggunakan peluang ini guna membantu membentuk API untuk memastikan bahwa API tersebut sudah mewakili hal yang kami harapkan dapat diukur dengan hal ini.

Ucapan terima kasih

Gambar thumbnail oleh Jordan Madrid di Unsplash