Mengukur navigasi ringan

Barry Pollard

Michal Mocny

Dipublikasikan: 1 Februari 2023, Terakhir diperbarui: 24 Juni 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 web satu halaman yang populer tidak pernah didukung sepenuhnya oleh Core Web Vitals. 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 Core Web Vitals diukur untuk hal ini—dengan cara yang serupa dengan pengukuran situs yang diimplementasikan dalam arsitektur multi-halaman (MPA) konvensional.

Kami telah melakukan beberapa peningkatan pada proposal berdasarkan masukan developer dan berencana meluncurkan dua API performa baru untuk membantu menyelesaikan masalah ini mulai dari Chrome 151.

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 pengecatan yang terlihat.

Untuk beberapa situs, definisi 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.

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 deteksi 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 dalam tampilan Metrik Langsung akan ditambahkan nanti.

Bagaimana cara Chrome menerapkan navigasi ringan untuk developer web?

Setelah fitur 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 paintful content. Entri ini akan berisi entri largestContentfulPaint yang dapat digunakan untuk mengukur Largest Contentful Paint (LCP) untuk navigasi dinamis.
• 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 fungsi getLargestInteractionContentfulPaint() untuk mengambil entri interaction-contentful-paint terbesar untuk navigasi tersebut. 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. Perhatikan bahwa hal ini menggantikan atribut largestInteractionContentfulPaint yang tersedia dalam uji coba origin sebelumnya.
• Mungkin beberapa entri interaction-contentful-paint terjadi sebelum navigasi ringan berlangsung (jika update URL tidak terjadi hingga setelah rendering tersebut). Dalam kasus ini, fungsi getLargestInteractionContentfulPaint() tidak perlu melakukan buffering dan melihat kembali entri lama setelah navigasi ringan selesai. Perhatikan bahwa entri yang ditampilkan oleh getLargestInteractionContentfulPaint() adalah salinan persis dari entri interaction-contentful-paint terbesar pada saat entri tersebut dikeluarkan, sehingga entri tersebut mungkin telah 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 dipancarkan setelah interaksi lebih lanjut, tetapi LCP untuk URL harus dibatasi pada entri interaction-contentful-paint yang cocok dengan navigasi ringan interactionId untuk mengecualikan entri ini dan juga hanya pada properti largestContentfulPaint di dalamnya.

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 fitur Navigasi Lembut 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 sementara diukur sehingga LCP untuk pemuatan halaman navigasi keras awal dapat diukur seperti sebelumnya.
• Entri interaction-contentful-paint baru yang akan dikeluarkan dari interaksi dapat digunakan untuk mengukur LCP untuk navigasi ringan dengan melihat properti largestContentfulPaint di dalamnya, tetapi ada beberapa pertimbangan tentang cara menggunakan entri ini yang akan kita bahas dalam artikel ini.
• Perhatikan bahwa tidak semua pengguna akan mendukung fitur 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.

Tanyakan kepada provider RUM Anda apakah mereka mendukung pengukuran Core Web Vitals 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?

Fitur navigasi ringan ditujukan untuk diaktifkan secara default di Chrome 151, tetapi tersedia untuk pengujian sebelum itu 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.

Beberapa pemilik situs juga telah mengaktifkannya di situs sebelum peluncuran melalui proses uji coba origin. Perlu diketahui bahwa bentuk API telah berubah selama pengembangan fitur dan fitur akhir yang dikirimkan berbeda dari uji coba origin sebelumnya seperti yang dijelaskan dalam Log Perubahan Navigasi Lembut

Mendeteksi dukungan Soft Navigations API fitur

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 deteksi navigasi ringan diaktifkan, metrik akan dilaporkan menggunakan API PerformanceObserver seperti metrik lainnya. 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 siklus proses penuh untuk navigasi sebelumnya.

Melaporkan metrik terhadap URL yang sesuai

Saat navigasi ringan terlihat, Core Web Vitals 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 web satu halaman).

ID ini harus ditetapkan sebagai setiap entri soft-navigation dan digunakan untuk melaporkan metrik hingga entri soft-navigation berikutnya diterima.

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 paint 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 bahwa interaction-contentful-paint, entri akan terus dipancarkan 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 fungsi getLargestInteractionContentfulPaint() 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 Core Web Vitals 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 sama dengan memetakan ke entri soft-navigation yang sesuai dan menggunakan startTime-nya.

startTime adalah waktu interaksi awal (misalnya, klik tombol) yang memulai navigasi sementara. 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 Core Web Vitals, dengarkan entri soft-navigation, reset metrik saat menerima entri ini. FCP dapat dikeluarkan berdasarkan presentationTime dan LCP dapat diinisialisasi ke entri getLargestInteractionContentfulPaint(). INP, CLS, harus diinisialisasi ke 0 seperti yang akan dilakukan untuk pemuatan halaman.

LCP, INP, dan CLS kemudian dapat diukur dan dipantau seperti biasa (kecuali penggunaan interaction-contentful-paint untuk LCP yang menyediakan kecocokan interactionId). interactionId 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: LCP, misalnya, 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 Core Web Vitals 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 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 ringan 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 awal? 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 dan yang kami rekomendasikan untuk metrik ini saat ini.

Haruskah Anda mengukur Core Web Vitals dengan kedua metodologi tersebut?

Meskipun API baru ini hanya tersedia untuk browser berbasis Chromium, situs mungkin ingin mengukur keduanya dengan mengelompokkan menurut navigasi ringan, dan dengan terus mengelompokkan menurut navigasi berat. Hal ini akan memungkinkan perbandingan di seluruh browser dan untuk tren historis.

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, ini berarti mengukur CLS dan INP di seluruh siklus proses halaman seperti yang terjadi pada cara saat ini, dan membagi linimasa secara terpisah berdasarkan navigasi ringan untuk mengukur nilai CLS dan INP yang terpisah untuk yang baru.

Kemudian, metrik tersebut perlu dikirimkan dan disimpan dua kali untuk dianalisis.

Gunakan library web-vitals untuk mengukur Core Web Vitals 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?

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 setelah API diluncurkan.

Kami menghargai masukan developer web tentang API dan apakah Anda merasa API tersebut lebih akurat 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 pelaporan navigasi ringan di CrUX setelah fitur diluncurkan juga masih harus ditentukan. Kami akan mengumumkan perubahan CrUX jika ada informasi lebih lanjut yang dapat kami bagikan di sini.

Masukan

Kami secara aktif mencari masukan tentang API 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 dikirimkan ke web-vitals-feedback@googlegroups.com.

Jika Anda ragu, jangan terlalu khawatir. Kami lebih suka menerima 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

Saat API ini dikembangkan, sejumlah perubahan telah terjadi padanya, lebih banyak daripada API stabil. Anda dapat melihat Log Perubahan Navigasi Lembut untuk mengetahui detail selengkapnya.

Kesimpulan

Fitur Navigasi Lembut adalah pendekatan menarik tentang bagaimana inisiatif Core Web Vitals dapat berkembang untuk mengukur pola umum di web modern yang tidak ada dalam metrik kami. Kami telah mengumpulkan banyak masukan dari komunitas web yang lebih luas dan 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.

Ucapan terima kasih

Gambar thumbnail oleh Jordan Madrid di Unsplash

Pekerjaan ini adalah 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.