Chrome 151’s Soft Navigations API akhirnya membolehkan aplikasi halaman tunggal (SPA) melaporkan Core Web Vitals bagi setiap navigasi dalam aplikasi, tetapi set data CrUX Google masih hanya merekodkan muatan keras (hard load) yang pertama, meninggalkan pembangun dengan dua gambaran prestasi yang berbeza.

Mengapa metrik SPA ketinggalan

Core Web Vitals—Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) dan Cumulative Layout Shift (CLS)—ditakrifkan berdasarkan navigasi keras (hard navigations). Navigasi keras mengambil dokumen yang benar-benar baharu dan membuang keadaan (state) halaman sebelumnya.

SPA yang dibina dengan React, Vue, Next.js, atau rangka kerja (framework) serupa jarang mencetuskan navigasi keras. Mengklik pautan akan mengemas kini URL melalui History API, mengambil data di latar belakang, dan menukar kandungan tanpa muat semula sepenuhnya. Performance API sedia ada hanya menangkap muatan halaman awal, jadi LCP dan INP tidak dapat melihat kependaman (latency) yang dirasai pengguna apabila mereka berpindah dari satu laluan (route) ke laluan yang lain.

Titik buta tersebut menjejaskan papan pemuka (dashboard) yang menarik data daripada Performance Timeline atau Chrome User Experience Report (CrUX) Google. Ia sering menunjukkan LCP yang cemerlang untuk halaman "shell" tetapi mengabaikan muatan yang lebih perlahan di bahagian yang lebih dalam dalam aplikasi, memberikan gambaran kesihatan prestasi yang palsu.

API Soft Navigations Chrome

Chrome 151 memperkenalkan Soft Navigations API, satu set heuristik yang menganggap interaksi SPA tertentu sebagai navigasi sebenar. API ini memerhatikan tiga isyarat:

  • Interaksi yang dimulakan oleh pengguna (klik, ketik, acara papan kekunci)
  • Perubahan URL melalui History API
  • Acara lukisan (paint events) seterusnya yang memaparkan kandungan baharu

Apabila ketiga-tiga isyarat ini selari, Chrome merekodkan soft navigation dalam Performance Timeline, dan Core Web Vitals dikira untuk peralihan tersebut sama seperti navigasi keras. Pustaka (library) sumber terbuka web-vitals telah menambah sokongan pada 21 Julai, jadi pembangun boleh mula menarik angka-angka ini dengan API yang sama yang mereka gunakan sekarang.

Secara praktikal, anda kini dapat melihat nilai LCP bagi setiap perubahan laluan, INP yang mencerminkan kependaman sebenar input pengguna terakhir, dan CLS yang menangkap anjakan susun atur (layout shifts) selepas soft navigation.

Perpecahan data: Chrome lwn. CrUX

CrUX (Chrome User Experience Report) Google memacu PageSpeed Insights, Search Console dan, secara tidak langsung, isyarat kedudukan (ranking signals). CrUX masih hanya mengumpulkan data navigasi keras.

Akibatnya, anda akan mendapat dua aliran data yang konsisten tetapi berbeza:

  • Alatan dalaman yang membaca Performance Timeline kini menunjukkan LCP, INP dan CLS pada peringkat laluan, memberikan pandangan realistik tentang apa yang dialami pengguna dalam SPA.
  • Set data awam Google terus menunjukkan metrik untuk muatan halaman pertama sahaja, iaitu apa yang dilaporkan oleh Search Console dan apa yang dirujuk oleh algoritma kedudukan Google.

Kedua-duanya adalah betul; mereka cuma mengukur detik yang berbeza. Bergantung semata-mata pada Search Console boleh menyembunyikan kemerosotan prestasi (performance regressions) yang berlaku selepas muatan awal, manakala papan pemuka dalaman sahaja tidak akan mencerminkan garis dasar (baseline) yang digunakan oleh Google untuk SEO.

Apa yang perlu diperhatikan oleh pembangun

  • Sokongan pelayar – API Soft Navigations buat masa ini hanya tersedia dalam pelayar berasaskan Chromium. Safari dan Firefox tidak mempunyai persamaan, jadi anda mesti mengekalkan logik sandaran (fallback logic) untuk sebahagian daripada audiens anda.
  • Had heuristik – API ini menentukan soft navigation berdasarkan satu set petunjuk. Jika aplikasi anda mengemas kini kandungan tanpa mengubah URL (contohnya, tindanan modal atau skrol infiniti), API mungkin terlepas peralihan tersebut, meninggalkan jurang dalam data.
  • Ujian sebelum percaya – Oleh kerana pengesanan adalah bersifat heuristik, jalankan siri interaksi dunia sebenar pada aplikasi anda dan bandingkan metrik yang dilaporkan dengan pemasaan manual (contohnya, menggunakan performance.mark). Hanya selepas mengesahkan ketepatan, barulah anda patut membuat keputusan pengoptimuman berdasarkan angka baharu tersebut.

Kesimpulan

Chrome 151 memberikan pembangun SPA keupayaan yang telah lama dinantikan untuk mengukur LCP, INP dan CLS bagi setiap perubahan laluan dalam aplikasi, tetapi data kedudukan Google masih hanya mencerminkan muatan keras pertama. Sehingga CrUX mengejar ketertinggalan, pasukan mesti mengendalikan dua set data selari: satu yang menceritakan kisah sebenar pengguna, dan satu lagi yang memacu kedudukan carian. Mengimbangi kedua-duanya—dan bersedia untuk sokongan pelayar yang lebih luas—akan menjadi kunci untuk mengekalkan SPA yang mengutamakan prestasi dalam ekosistem web yang kompetitif.