Bereksperimen dengan pengukuran navigasi ringan

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

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. 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 persepsi pengguna tentang performa halaman. Oleh karena itu, teknologi yang digunakan untuk membuat situs tidak akan memengaruhi penskoran selama situs berperforma baik.

Kenyataannya selalu sedikit lebih rumit daripada yang ideal, dan arsitektur Aplikasi Web Satu Halaman yang populer tidak pernah didukung sepenuhnya oleh metrik Data Web Inti. Aplikasi web ini menggunakan "navigasi lembut", bukan memuat halaman web individual yang berbeda saat pengguna menjelajahi situs, dengan konten halaman 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 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 membuat fitur yang telah diimplementasikan tersedia secara lebih luas bagi situs untuk bereksperimen. Dengan begitu, situs dapat memberikan masukan terkait pendekatan yang telah dilakukan.

Apa yang dimaksud dengan navigasi halus?

Kami telah membuat definisi navigasi halus 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 (saat pengguna tidak 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 tentang heuristik.

Bagaimana cara Chrome menerapkan navigasi soft?

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

  • Peristiwa soft-navigation PerformanceTiming akan ditampilkan setelah setiap navigasi soft terdeteksi.
  • Performance API akan memberikan akses ke entri pengaturan waktu soft-navigation, seperti yang dikeluarkan oleh peristiwa soft-navigation PerformanceTiming.
  • Metrik First Paint (FP), First Contentful Paint (FCP), Largest Contentful Paint (LCP) akan direset, dan ditampilkan kembali pada kemunculan berikutnya yang sesuai. (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 Data Web Inti—dan beberapa metrik diagnostik terkait—diukur per navigasi halaman, meskipun ada beberapa nuansa 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. Laporan Pengalaman Pengguna Chrome (CrUX) akan mengabaikan nilai tambahan ini, tetapi hal ini dapat memengaruhi pemantauan Pengukuran Pengguna Sebenarnya (RUM) di situs Anda. Hubungi penyedia RUM jika Anda memiliki kekhawatiran jika hal ini akan memengaruhi pengukuran tersebut. Lihat bagian tentang mengukur Data Web Inti untuk navigasi halus.
  • 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 metrik yang lebih 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. Perhatikan 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 lain yang tidak diinginkan.

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

Bagaimana cara mengaktifkan navigasi halus di Chrome?

Navigasi lembut 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 soft?

Setelah eksperimen navigasi halus diaktifkan, metrik akan dilaporkan menggunakan PerformanceObserver API seperti biasa. Namun, ada beberapa pertimbangan tambahan yang perlu dipertimbangkan untuk metrik ini.

Melaporkan navigasi soft

Anda dapat menggunakan PerformanceObserver untuk mengamati navigasi soft. Berikut adalah contoh cuplikan kode yang mencatat entri navigasi soft ke konsol—termasuk navigasi soft 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 berdasarkan URL yang sesuai

Karena navigasi soft 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 peristiwa kembali ke URL yang benar. Hal ini dapat dilihat 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 soft

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 soft, dilaporkan sebagai waktu dari waktu navigasi halaman "hard" awal. Oleh karena itu, waktu mulai navigasi soft diperlukan untuk menetapkan dasar pengukuran waktu metrik pemuatan navigasi soft (misalnya LCP), yang relatif terhadap waktu navigasi soft ini.

Mengukur Core Web Vitals per navigasi ringan

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

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 untuk mengaktifkan fitur navigasi halus di Chrome. Keikutsertaan eksplisit ini di tingkat observer performa bertujuan untuk memastikan observer performa yang ada tidak terkejut dengan entri tambahan ini karena beberapa pertimbangan tambahan perlu dipertimbangkan saat mencoba mengukur Data Web Inti untuk navigasi halus.

Waktu akan tetap ditampilkan sehubungan dengan waktu mulai navigasi "hard" asli. Jadi, untuk menghitung LCP untuk navigasi halus, misalnya, Anda harus mengambil pengaturan waktu LCP dan mengurangi waktu mulai navigasi halus yang sesuai seperti yang dijelaskan sebelumnya untuk mendapatkan pengaturan waktu yang relatif terhadap navigasi halus. 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 ditutup. Oleh karena itu, setiap "navigasi" (termasuk navigasi asli) mungkin perlu menyelesaikan metrik halaman sebelumnya saat setiap navigasi soft baru terjadi. Artinya, metrik navigasi "hard" awal dapat diselesaikan lebih awal dari biasanya.

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 memori nilai yang ditetapkan untuk "halaman" sebelumnya.

Bagaimana konten yang tetap sama di antara navigasi harus diperlakukan?

FP, FCP, dan LCP untuk navigasi soft hanya akan mengukur cat baru. Hal ini dapat menghasilkan LCP yang berbeda, misalnya, dari pemuatan dingin 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 halus. Pemuatan halaman awal akan menandai gambar banner sebagai elemen LCP dan mendasarkan waktu LCP pada hal tersebut. Untuk navigasi soft berikutnya, teks di bawahnya akan menjadi elemen terbesar yang digambar setelah navigasi soft 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 permintaan asli ditampilkan.

Untuk navigasi soft, 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 halus dari perspektif pengguna (misalnya, permintaan analisis)?

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

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

Bagaimana cara mengukur performa lama dan baru?

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

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

Untuk mengukur keduanya, Anda perlu mengetahui peristiwa baru yang mungkin dikeluarkan saat dalam mode navigasi halus (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 halus.

Menggunakan library web-vitals untuk mengukur Data Web Inti untuk navigasi halus

Cara termudah untuk mempertimbangkan semua nuansa tersebut adalah dengan menggunakan library JavaScript web-vitals yang memiliki dukungan eksperimental untuk navigasi virtual di soft-navs branch terpisah (yang juga tersedia di npm dan unpkg). Hal ini dapat diukur dengan cara berikut (mengganti doTraditionalProcessing dan doSoftNavProcessing sebagaimana mestinya):

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 telah disebutkan sebelumnya.

Library web-vitals melaporkan metrik berikut untuk navigasi soft:

Metrik Detail
TTFB Dilaporkan sebagai 0.
FCP Hanya FCP pertama untuk halaman yang dilaporkan.
LCP Waktu contentful paint terbesar berikutnya, relatif terhadap waktu mulai navigasi virtual. Cat yang ada dari navigasi sebelumnya tidak dipertimbangkan. Oleh karena itu, LCP akan >= 0. Seperti biasa, hal ini akan dilaporkan setelah interaksi, atau saat halaman berada di latar belakang, karena hanya dengan demikian LCP dapat diselesaikan.
CLS Periode pergeseran terbesar antara waktu navigasi. Seperti biasa, ini terjadi saat halaman berada di latar belakang karena hanya saat itulah CLS dapat diselesaikan. Nilai 0 dilaporkan jika tidak ada pergeseran.
INP INP antara waktu navigasi. Seperti biasa, hal ini akan dilaporkan setelah interaksi, atau saat halaman berada di latar belakang karena hanya dengan begitu INP dapat diselesaikan. Nilai 0 tidak dilaporkan jika tidak ada interaksi.

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 kami membuat keputusan apakah heuristik 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 masukan developer web tentang eksperimen, heuristik yang digunakan, dan apakah Anda merasa eksperimen tersebut lebih akurat mencerminkan pengalaman. Repositori GitHub navigasi halus adalah tempat terbaik untuk memberikan masukan tersebut, meskipun bug individual pada penerapan navigasi halus di Chrome harus dilaporkan di pelacak masalah Chrome.

Bagaimana navigasi lunak akan dilaporkan di CrUX?

Cara navigasi soft akan dilaporkan di CrUX, jika eksperimen ini berhasil, juga masih harus ditentukan. Tidak harus mengingat bahwa navigasi tersebut akan diperlakukan sama seperti navigasi "keras" saat ini 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. Di kasus lain, iklan tersebut 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. Kita mungkin juga dapat mengecualikan navigasi soft pemuatan parsial sepenuhnya, seiring dengan perkembangan 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 secara aktif mencari masukan tentang eksperimen ini di tempat berikut:

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 Soft untuk mengetahui detail selengkapnya.

Kesimpulan

Eksperimen navigasi halus adalah pendekatan yang menarik untuk mengetahui 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 menyarankan bagi yang tertarik dengan pengembangan ini untuk menggunakan kesempatan ini guna membantu membentuk API untuk memastikan API tersebut mewakili hal yang ingin kami ukur dengan ini.

Ucapan terima kasih

Gambar thumbnail oleh Jordan Madrid di Unsplash