API Soft Navigations di Chrome 151 akhirnya memungkinkan single-page apps (SPA) melaporkan Core Web Vitals untuk setiap navigasi di dalam aplikasi, namun dataset CrUX Google masih hanya mencatat pemuatan keras (hard load) pertama, sehingga pengembang menghadapi dua gambaran performa yang berbeda.

Mengapa metrik SPA tertinggal

Core Web Vitals—Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP), dan Cumulative Layout Shift (CLS)—didefinisikan di sekitar navigasi keras (hard navigation). Navigasi keras mengambil dokumen yang benar-benar baru dan membuang status halaman sebelumnya.

SPA yang dibangun dengan React, Vue, Next.js, atau framework serupa jarang memicu navigasi keras. Mengeklik tautan memperbarui URL melalui History API, mengambil data di latar belakang, dan menukar konten tanpa pemuatan ulang (reload) penuh. Performance API yang ada saat ini hanya menangkap pemuatan halaman awal, sehingga LCP dan INP tidak pernah mendeteksi latensi yang dirasakan pengguna saat mereka berpindah dari satu rute ke rute lainnya.

Titik buta tersebut mengacaukan dasbor yang menarik data dari Performance Timeline atau Chrome User Experience Report (CrUX) milik Google. Dasbor tersebut sering kali menunjukkan LCP yang sangat baik untuk halaman "shell", namun mengabaikan pemuatan yang lebih lambat di bagian aplikasi yang lebih dalam, sehingga memberikan kesan kesehatan performa yang semu.

API Soft Navigations Chrome

Chrome 151 memperkenalkan Soft Navigations API, sekumpulan heuristik yang memperlakukan interaksi SPA tertentu sebagai navigasi nyata. API ini memantau tiga sinyal:

  • Interaksi yang dimulai pengguna (klik, ketukan, peristiwa keyboard)
  • Perubahan URL melalui History API
  • Peristiwa paint berikutnya yang merender konten baru

Ketika ketiganya selaras, Chrome mencatat soft navigation dalam Performance Timeline, dan Core Web Vitals dihitung untuk transisi tersebut sama seperti navigasi keras. Library open-source web-vitals telah menambahkan dukungan pada 21 Juli, sehingga pengembang dapat mulai menarik angka-angka ini dengan API yang sama yang sudah mereka gunakan.

Dalam praktiknya, Anda sekarang dapat melihat nilai LCP untuk setiap perubahan rute, INP yang mencerminkan latensi sebenarnya dari input pengguna terakhir, dan CLS yang menangkap pergeseran tata letak (layout shift) setelah soft navigation.

Perpecahan data: Chrome vs. CrUX

CrUX (Chrome User Experience Report) milik Google menggerakkan PageSpeed Insights, Search Console, dan secara tidak langsung, sinyal peringkat. CrUX masih hanya mengagregasi data navigasi keras.

Akibatnya, Anda akan mendapatkan dua aliran data yang konsisten tetapi berbeda:

  • Alat internal yang membaca Performance Timeline kini menunjukkan LCP, INP, dan CLS pada tingkat rute, memberikan pandangan realistis tentang apa yang dialami pengguna dalam sebuah SPA.
  • Dataset publik Google terus menunjukkan metrik hanya untuk pemuatan halaman pertama, yang merupakan apa yang dilaporkan Search Console dan apa yang dijadikan referensi oleh algoritma peringkat Google.

Keduanya benar; mereka hanya mengukur momen yang berbeda. Mengandalkan Search Console saja dapat menutupi penurunan performa (performance regression) yang terjadi setelah pemuatan awal, sementara dasbor internal saja tidak akan mencerminkan baseline yang digunakan Google untuk SEO.

Apa yang perlu diperhatikan pengembang

  • Dukungan browser – Saat ini, Soft Navigations API hanya tersedia di browser berbasis Chromium. Safari dan Firefox belum memiliki padanan yang setara, jadi Anda harus tetap menyediakan logika fallback untuk sebagian audiens Anda.
  • Batasan heuristik – API ini menentukan soft navigation berdasarkan sekumpulan petunjuk. Jika aplikasi Anda memperbarui konten tanpa mengubah URL (misalnya, overlay modal atau infinite scroll), API mungkin melewatkan transisi tersebut, sehingga meninggalkan celah dalam data.
  • Pengujian sebelum mempercayai – Karena deteksinya bersifat heuristik, jalankan serangkaian interaksi dunia nyata pada aplikasi Anda dan bandingkan metrik yang dilaporkan dengan penandaan waktu manual (misalnya, menggunakan performance.mark). Hanya setelah mengonfirmasi akurasinya, Anda boleh mendasarkan keputusan optimasi pada angka-angka baru tersebut.

Intinya

Chrome 151 memberikan kemampuan yang telah lama dinantikan oleh pengembang SPA untuk mengukur LCP, INP, dan CLS untuk setiap perubahan rute di dalam aplikasi, tetapi data peringkat Google masih hanya mencerminkan pemuatan keras pertama. Hingga CrUX mengejar ketertinggalan, tim harus mengelola dua set data paralel: satu yang menceritakan pengalaman pengguna yang sebenarnya, dan satu lagi yang mendorong peringkat pencarian. Menyeimbangkan keduanya—serta bersiap untuk dukungan browser yang lebih luas—akan menjadi kunci untuk mempertahankan SPA yang mengutamakan performa dalam ekosistem web yang kompetitif.