Bereksperimen dengan pengukuran navigasi ringan

Barry Pollard

Michal Mocny

Dipublikasikan: 1 Februari 2023, Terakhir diperbarui: 30 Maret 2026

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 Core Web Vitals untuk hal ini—dengan cara yang serupa dengan cara pengukuran situs yang diimplementasikan dalam arsitektur multi-halaman (MPA) konvensional.

Kami telah melakukan beberapa peningkatan pada API berdasarkan masukan developer untuk uji coba origin terakhir dan sekarang meminta developer untuk mencoba iterasi terbaru dan memberikan masukan tentang pendekatan ini sebelum diluncurkan. Kami cukup yakin dengan posisi API setelah melalui iterasi ini dan berencana meluncurkan API tersebut pada tahun ini, bergantung pada masukan terkait uji coba origin terbaru ini.

Apa itu navigasi lembut?

Kami telah membuat definisi navigasi ringan berikut:

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

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.

Dukungan DevTools untuk Navigasi ringan

Kami telah menambahkan dukungan untuk navigasi ringan ke panel Performa DevTools dalam tampilan rekaman aktivitas:

Anda dapat melihat penanda untuk navigasi ringan dan LCP, yang keduanya ditandai dengan * untuk membantu membedakannya dari entri navigasi berat biasa. Fitur ini diaktifkan secara default dan terpisah dari perubahan API performa yang akan kita bahas selanjutnya. Ini adalah cara cepat untuk menguji apakah eksperimen navigasi lembut berfungsi dengan benar untuk situs Anda.

Untuk saat ini, hanya navigasi ringan dan stempel waktu LCP yang ditampilkan dalam tampilan rekaman aktivitas. Metrik lain (misalnya LCP) dan dukungan di tampilan Metrik Langsung akan ditambahkan nanti.

Bagaimana cara Chrome menerapkan navigasi ringan untuk developer web?

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.
• Entri soft-navigation ini akan menyertakan navigationId, URL baru dalam atribut name, serta interactionId dari interaksi yang memulai.
• Satu atau beberapa entri interaction-contentful-paint akan dikeluarkan setelah interaksi yang menyebabkan paint konten. Hal ini dapat digunakan untuk mengukur Largest Contentful Paint (LCP) untuk navigasi ringan saat interaksi memancarkan navigasi ringan.
• Atribut navigationId ditambahkan ke setiap 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 saat entri ini mencakup navigasi ringan, entri tersebut dapat berisi navigationId sebelumnya atau berikutnya, bergantung pada kapan entri dikeluarkan. Informasi selengkapnya tentang hal ini ada di bagian Laporkan metrik terhadap URL yang sesuai.
• soft-navigation akan menyertakan entri largestInteractionContentfulPaint yang mencakup entri interaction-contentful-paint terbesar yang dikeluarkan sebagai bagian dari navigasi. LCP 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.
• Mungkin beberapa entri interaction-contentful-paint terjadi sebelum navigasi ringan berlangsung (jika update URL tidak terjadi hingga setelah rendering tersebut). Dalam kasus ini, entri largestInteractionContentfulPaint terbesar tidak perlu melakukan buffering dan melihat kembali entri lama. Perhatikan bahwa largestInteractionContentfulPaint adalah salinan persis dari entri interaction-contentful-paint terbesar, sehingga entri tersebut akan menggunakan navigationId sebelumnya karena saat itulah paint terjadi, tetapi paint ini harus diukur terhadap navigationId baru.
• Entri soft-navigation juga akan menyertakan paintTime dan presentationTime sebagai FCP untuk navigasi tersebut.
• Perhatikan bahwa entri interaction-contentful-paint juga akan dikeluarkan setelah interaksi lebih lanjut, tetapi LCP untuk URL harus dibatasi ke entri interaction-contentful-paint yang cocok dengan navigasi ringan interactionId untuk mengecualikan entri ini.

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:

• Memantau entri soft-navigation memungkinkan "pengelompokan" entri performa ke dalam setiap "navigasi".
• Metrik CLS dan INP sudah dapat dikelompokkan sesuai keinginan Anda, bukan diukur selama durasi siklus proses seluruh halaman, tetapi Soft Navigation API memberikan pengukuran standar saat hal ini terjadi, terlepas dari teknologi pokok yang digunakan.
• Entri largest-contentful-paint diselesaikan pada interaksi (yang diperlukan untuk memulai navigasi ringan), sehingga hanya dapat digunakan untuk mengukur LCP navigasi "berat" awal. Artinya, nilai ini tidak akan berubah saat navigasi ringan diukur sehingga LCP untuk pemuatan halaman navigasi berat awal dapat diukur seperti sebelumnya.
• Entri interaction-contentful-paint baru yang akan dikeluarkan dari interaksi dapat digunakan untuk mengukur LCP untuk navigasi ringan, tetapi ada beberapa pertimbangan tentang cara menggunakan entri ini yang akan kita bahas dalam artikel ini.
• Perhatikan bahwa tidak semua pengguna akan mendukung API navigasi ringan ini, terutama untuk versi Chrome yang lebih lama, dan bagi mereka yang menggunakan browser lain. Perlu diketahui bahwa beberapa pengguna mungkin tidak melaporkan metrik berbasis 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 berdasarkan 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. Atau, fitur ini dapat diaktifkan dengan menggunakan argumen command line --enable-features=SoftNavigationHeuristics saat meluncurkan Chrome. Mengaktifkan tanda chrome://flags/#enable-experimental-web-platform-features juga akan mengaktifkan navigasi ringan.

Untuk situs yang ingin mengaktifkan fitur ini agar semua pengunjungnya dapat melihat dampaknya, akan ada uji coba origin yang berjalan dari Chrome 147 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 terkait perubahan 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 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.

Mendeteksi dukungan Soft Navigations API

Anda dapat menggunakan kode berikut untuk menguji apakah API didukung:

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

Perhatikan bahwa supportedEntryTypes dibekukan saat pertama kali digunakan. Jadi, jika dukungan navigasi ringan ditambahkan secara dinamis oleh token uji coba origin yang disuntikkan ke halaman, maka nilai asli dapat ditampilkan sebelum fitur tersebut diaktifkan.

Alternatif berikut dapat digunakan dalam kasus ini saat navigasi lembut belum didukung secara default dan berada dalam status transisi ini:

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

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 sementara ke konsol—termasuk navigasi sementara 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

Saat navigasi ringan terlihat, Data Web Inti 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 halaman tunggal). 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;

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 dipancarkan sebelum navigasi ringan terjadi jika pengecatan terjadi sebelum update URL. Dalam kasus ini, navigationId akan ditujukan untuk URL lama. Jika URL diperbarui terlebih dahulu, maka paint akan menyelesaikan navigasi ringan dan dalam hal ini entri soft-navigation akan dikeluarkan terlebih dahulu, dan interaction-contentful-paint akan memiliki URL baru.
• Masalah kedua adalah interaction-contentful-paint, entri akan terus dikeluarkan untuk interaksi yang lebih baru, karena cakupan metrik performa ini melampaui hanya LCP untuk navigasi ringan. Kita hanya ingin mempertimbangkan paint untuk pemuatan navigasi ringan untuk LCP, bukan paint 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 semua entri dengan navigationId lama serta memfilter semua entri interaction-contentful-paint yang tidak boleh dipertimbangkan untuk LCP.

Selain itu, Anda juga harus mempertimbangkan untuk memproses entri largestInteractionContentfulPaint dari entri soft-navigation, agar lebih mudah menangani entri interaction-contentful-paint yang terjadi sebelum soft-navigation entries dipancarkan.

Mendapatkan startTime navigasi ringan

Semua waktu performa, termasuk yang untuk navigasi ringan, dan entri yang digunakan untuk menghitung metrik Data Web Inti 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 relatif terhadap waktu navigasi ringan ini.

Waktu mulai navigasi dapat diperoleh dengan cara yang serupa 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 "navigasi berat", di mana "waktu mulai" 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 Data Web Inti, dengarkan entri soft-navigation, reset metrik saat menerimanya. FCP dapat dikeluarkan berdasarkan presentationTime dan LCP dapat diinisialisasi ke largestInteractionContentfulPaint. INP, CLS, harus diinisialisasi ke 0 seperti yang akan dilakukan untuk pemuatan halaman.

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

Waktu masih akan 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.

Beberapa metrik secara tradisional diukur selama masa aktif halaman: Misalnya, LCP dapat berubah hingga interaksi terjadi. CLS dan INP dapat diperbarui hingga pengguna keluar dari halaman, terlepas dari interaksi apa pun. Oleh karena itu, metrik navigasi sebelumnya harus diselesaikan saat setiap navigasi ringan baru terjadi. Artinya, metrik navigasi "berat" awal dapat diselesaikan lebih awal dari biasanya saat mengukur Data Web Inti dengan navigasi ringan.

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. 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 ditangani?

LCP untuk navigasi ringan (dihitung dari interaction-contentful-paint) hanya akan mengukur paint baru, dan hanya paint yang terkait dengan interaksi yang menyebabkan navigasi. 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 lembut. Pemuatan halaman awal akan menandai gambar banner sebagai elemen LCP dan mendasarkan pengaturan 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 dimuat dengan deep link ke URL navigasi ringan, gambar banner akan menjadi proses menggambar baru dan oleh karena itu akan memenuhi syarat untuk dianggap sebagai elemen LCP.

Demikian pula, animasi dapat memperbarui sebagian halaman secara terus-menerus—tidak terkait dengan navigasi lembut yang terjadi. Setiap gambar baru karena animasi latar belakang tersebut tidak akan dipertimbangkan untuk LCP navigasi lembut baru. Namun, halaman 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 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 sementara dan yang kami rekomendasikan untuk metrik ini saat ini.

Haruskah Anda mengukur Core Web Vitals dengan kedua metodologi tersebut?

Selama eksperimen ini, sebaiknya terus ukur Data Web Inti Anda dengan cara saat ini, berdasarkan navigasi halaman "keras" karena penerapan baru mungkin memiliki masalah atau berubah sebelum akhirnya diluncurkan. Hal ini juga akan cocok dengan apa yang diukur CrUX untuk saat ini (info selengkapnya akan dibahas nanti).

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

Untuk LCP, maka 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, hal ini berarti mengukur CLS dan INP di seluruh siklus proses halaman seperti yang dilakukan pada cara saat ini, dan membagi linimasa secara terpisah menurut navigasi ringan untuk mengukur nilai CLS dan INP yang terpisah untuk yang 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';

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 yang dilaporkan terhadap URL yang benar seperti yang disebutkan sebelumnya, karena metrik tersebut mencakup 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?

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. Tujuan utamanya adalah menyediakan cara untuk mengukur performa dengan lebih baik sebagai pengalaman pengguna nyata. Jadi, ya, tujuannya adalah menyertakan metrik ini dalam pengukuran Core Web Vitals sebagaimana yang ditampilkan oleh semua alat jika eksperimen ini berhasil.

Kami menghargai masukan developer web tentang eksperimen, heuristik yang digunakan, dan apakah Anda merasa heuristik tersebut lebih akurat dalam mencerminkan pengalaman. Repositori GitHub navigasi ringan 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 "berat" 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 tentang metrik penting web dapat disampaikan di 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 di Google. Kami berterima kasih kepada Yoav atas upayanya dalam mengembangkan API ini.