Jawaban atas pertanyaan umum tentang SPA, Core Web Vitals, dan cara Core Web Vitals memperlakukannya.
Dipublikasikan: 14 September 2021, Terakhir diperbarui: 11 Agustus 2026
Sejak pertama kali memperkenalkan inisiatif Web Vitals pada Mei 2020, kami di tim Chrome telah menerima banyak pertanyaan dan masukan yang bagus tentang program ini.
Mungkin topik yang paling banyak kami terima pertanyaannya, yang juga mungkin merupakan pertanyaan tersulit untuk dijawab, adalah cara mengukur Core Web Vitals dalam aplikasi halaman tunggal (SPA), serta cara arsitektur SPA memengaruhi skor Core Web Vitals.
Pertanyaan ini sulit dijawab karena masalahnya cukup rumit, jadi dalam postingan ini, kami akan berupaya sebaik mungkin untuk menjawab pertanyaan yang paling umum, dengan memberikan detail dan konteks sebanyak yang kami bisa.
Namun, sebelum membahas secara spesifik, penting untuk menyatakan bahwa Google tidak memiliki preferensi terkait arsitektur atau teknologi yang digunakan untuk membangun situs. Kami yakin bahwa aplikasi halaman tunggal (SPA) dan aplikasi multi-halaman (MPA) sama-sama mampu memberikan pengalaman berkualitas tinggi kepada pengguna, dan tujuan kami dengan inisiatif Data Web adalah menyediakan metrik yang mengukur pengalaman terlepas dari teknologinya.
Pertanyaan umum (FAQ)
Berikut adalah beberapa pertanyaan paling umum yang kami terima terkait topik ini. Kami dengan senang hati menerima masukan untuk ditambahkan ke FAQ ini di grup masukan kami atau dengan mengajukan masalah.
Apakah metrik Core Web Vitals mencakup transisi rute SPA?
Saat pertama kali diperkenalkan, setiap metrik Core Web Vitals diukur relatif terhadap navigasi halaman tingkat atas saat ini. Jika halaman memuat konten baru secara dinamis dan memperbarui URL halaman di kolom URL, hal itu tidak akan memengaruhi cara pengukuran metrik Core Web Vitals.
Nilai metrik tidak direset, dan URL yang terkait dengan setiap pengukuran metrik adalah URL yang dituju pengguna yang memulai pemuatan halaman.
Chrome 151 memperkenalkan API baru yang memungkinkan pengukuran Core Web Vitals di seluruh transisi rute SPA. Pada saat penulisan (Agustus 2026), API ini baru mulai digunakan di library pengukuran seperti web-vitals, solusi RUM, dan alat seperti Chrome DevTools. Chrome belum memublikasikan jangka waktu pengintegrasiannya ke dalam Chrome User Experience Report (CrUX). Selain itu, mesin browser lain belum mendukung API baru ini, sehingga Core Web Vitals hanya dapat diukur di seluruh pemuatan halaman penuh untuk browser tersebut.
Mengapa masalah ini sulit diselesaikan?
Saat ini, tidak ada cara standar untuk membangun SPA, dan bahkan di antara library SPA dan perutean yang populer, pengalaman pengguna dapat sangat berbeda dari aplikasi ke aplikasi:
- Beberapa SPA hanya memperbarui URL saat memuat konten "halaman penuh" baru, sedangkan situs lain memperbarui URL untuk perubahan konten kecil atau bahkan hanya perubahan status UI.
- Beberapa SPA memperbarui URL menggunakan History API, sedangkan yang lain menggunakan perubahan hash untuk mendukung browser lama (dan yang lain tidak memperbarui URL sama sekali).
- Beberapa SPA memuat konten lalu memperbarui URL, sedangkan SPA lainnya memperbarui URL sebelum memuat konten.
- Beberapa SPA memuat konten sekaligus, secara sinkron, dalam satu tugas JavaScript, sedangkan SPA lainnya melakukan transisi konten secara asinkron di beberapa tugas (tanpa peristiwa akhir transisi yang jelas).
- Beberapa SPA selalu memuat konten dari jaringan, sedangkan yang lain memuat semua konten terlebih dahulu sehingga perubahan rute dimuat secara instan dari memori.
Perbedaan ini membuat penentuan dan identifikasi apa yang merupakan perubahan rute SPA, atau bahkan SPA itu sendiri, sangat sulit dilakukan dalam skala besar.
Dalam beberapa kasus, perubahan rute SPA secara logis identik dengan pemuatan halaman MPA, dan dalam kasus tersebut, akan lebih baik jika metrik Core Web Vitals yang ada dapat diterapkan.
Namun, tanpa heuristik yang solid untuk mengidentifikasi perubahan rute "nyata" secara andal dari semua perubahan URL lainnya—serta sinyal yang jelas menandai awal dan akhir transisi tersebut—pelaporan metrik Core Web Vitals dalam kasus ini akan mengaburkan data dan membuatnya kurang berguna atau representatif dari pengalaman pengguna sebenarnya di situs.
Pengerjaan Navigasi Lembut telah memberikan solusi untuk masalah ini dengan dua API performa baru:
PerformanceSoftNavigationyang mengukur kapan interaksi pengguna menyebabkan paint dan perubahan URL. Kombinasi ketiga hal ini memberikan definisi standar "navigasi ringan" terlepas dari framework yang digunakan dan beberapa perbedaan yang disebutkan sebelumnya. Hal ini memungkinkan pemisahan linimasa performa menjadi beberapa "navigasi" terpisah, sehingga CLS dan INP dapat diukur untuk setiap navigasi.InteractionContentfulPaintyang mengukur "contentful paint" setelah interaksi, sehingga FCP dan LCP dapat diukur untuk navigasi ringan ini.
Kombinasi kedua API ini memungkinkan Core Web Vitals diukur di seluruh pemuatan halaman penuh dan navigasi ringan.
Apakah perubahan rute SPA sama dengan pemuatan halaman penuh untuk Core Web Vitals?
Tidak, masih ada banyak perbedaan antara jenis navigasi ini, yang dapat menghasilkan metrik Core Web Vitals yang berbeda.
Navigasi ringan memiliki konten di halaman dan memperbarui sebagian atau seluruh konten tersebut untuk menampilkan "halaman" baru. Dalam banyak hal, hal ini mirip dengan perbedaan antara pemuatan halaman penuh yang tidak di-cache dan pemuatan halaman saat beberapa atau semua resource halaman di-cache, tetapi dalam kondisi yang lebih ekstrem karena beberapa konten mungkin tetap dirender.
Secara teori, perbedaan utamanya adalah potensi navigasi ringan yang jauh lebih cepat. Namun, ada perbedaan lain yang lebih halus.
API navigasi lembut baru hanya mempertimbangkan konten baru. Jadi, halaman yang memperbarui <h1> dan konten teks, tetapi membiarkan gambar utama yang sama di antara halaman, tidak akan menganggap gambar utama sebagai kandidat LCP jika tidak melakukan pengecatan ulang. Hal ini akan menyebabkan perbedaan elemen yang digunakan untuk menghitung waktu LCP berdasarkan apakah halaman yang sama dimuat sebagai pemuatan halaman penuh, atau sebagai navigasi lembut dari halaman lain yang sudah ada.
Demikian pula, INP mungkin lebih rendah untuk navigasi ringan karena banyak JavaScript yang diperlukan untuk menjalankan situs akan dimuat. Dengan cara yang sama, navigasi ringan mungkin memiliki lebih sedikit (atau lebih banyak!) CLS jika konten yang sama menyebabkan CLS pada pemuatan halaman penuh, tetapi tidak perlu dimuat atau dirender ulang pada navigasi ringan.
Ada juga sedikit perbedaan dalam waktu pengambilan pengukuran dari pemuatan halaman penuh (diukur dari setelah pemrosesan interaksi navigasi) versus navigasi ringan (diukur dari waktu mulai interaksi).
Seperti yang dinyatakan sebelumnya, banyak perbedaan ini serupa dengan halaman yang tidak di-cache versus halaman yang di-cache, dan konsep tentang apa yang coba diukur oleh Core Web Vitals masih berlaku. Namun, sebaiknya pahami nuansa ini saat menyelidiki masalah Data Web Inti.
Apakah SPA lebih sulit mendapatkan hasil yang baik di Core Web Vitals dibandingkan MPA?
Tidak ada hal inheren dalam arsitektur SPA yang akan mencegah halaman di SPA dimuat secepat—dan mendapatkan skor sebaik—halaman serupa di MPA pada semua metrik Core Web Vitals.
Namun, MPA yang dioptimalkan dengan benar memiliki beberapa keunggulan dalam memenuhi nilai minimum Data Web Inti yang tidak dimiliki SPA. Hal ini sebagian besar telah diatasi dengan pekerjaan navigasi ringan yang dibahas sebelumnya, tetapi masih dapat terjadi jika API baru ini belum digunakan. Hal ini karena dengan arsitektur MPA, setiap "halaman" dimuat sebagai navigasi halaman penuh (bukan mengambil konten secara dinamis dan menyisipkannya ke halaman yang ada), yang berarti pengguna yang mengunjungi MPA lebih cenderung memuat lebih dari satu halaman dari situs, yang pada gilirannya berarti bahwa persentase yang lebih besar dari distribusi semua pemuatan halaman untuk MPA akan melibatkan beberapa atau semua sub-resource yang di-cache.
Memang, agar MPA berperforma lebih baik pada metrik Core Web Vitals daripada SPA, ada beberapa hal yang harus dipenuhi:
- MPA harus memiliki caching sub-resource yang dioptimalkan untuk memastikan pemuatan halaman origin yang sama memang lebih cepat daripada pemuatan halaman lintas origin pada persentil ke-75.
- Pengguna yang mengunjungi MPA harus membuka beberapa halaman agar situs dapat menerima manfaat penyimpanan ke dalam cache yang menghasilkan pemuatan halaman yang lebih cepat.
Karena penilaian Core Web Vitals mempertimbangkan persentil ke-75 kunjungan halaman, memiliki lebih banyak kunjungan halaman yang berperforma baik dalam set data akan meningkatkan kemungkinan kunjungan pada persentil ke-75 distribusi akan berada dalam nilai minimum yang direkomendasikan.
Perhatikan bahwa hal penting yang perlu dipertimbangkan saat membandingkan skor Core Web Vitals adalah cara data diagregasi, yaitu apakah set data dalam distribusi mencakup semua halaman dari situs atau origin Anda, atau hanya pemuatan halaman untuk URL halaman tertentu.
Saat menggabungkan skor semua halaman dalam suatu asal, setiap halaman cepat dapat meningkatkan persentil ke-75 untuk asal secara keseluruhan. Namun, saat menggabungkan berdasarkan halaman individual, skor satu halaman tidak akan memengaruhi skor halaman berikutnya. Dengan kata lain, saat menggabungkan skor MPA menurut halaman, pemuatan cache cepat yang terlihat di halaman checkout tidak akan meningkatkan skor pemuatan awal yang lambat yang dialami di halaman landing situs.
Anda dapat memeriksa skor situs untuk berbagai metode agregasi menggunakan PageSpeed Insights atau Chrome User Experience Report API, yang melaporkan skor untuk URL halaman individual dan seluruh situs asal.
Cara lain arsitektur SPA dapat memengaruhi skor Core Web Vitals adalah untuk metrik yang mempertimbangkan masa aktif penuh halaman. Karena pengguna yang mengunjungi SPA cenderung tetap berada di "halaman" yang sama selama seluruh sesi, metrik yang terakumulasi dari waktu ke waktu dapat lebih ketat pada SPA daripada MPA.
Dengan pekerjaan navigasi ringan, kami yakin bahwa tidak ada kerugian bagi SPA dalam hal cara pengukuran Core Web Vitals. Namun, integrasi penuh API ini di semua alat dan solusi pelaporan akan memerlukan waktu.
Jika arsitektur SPA meningkatkan pengalaman pengguna, bukankah peningkatan tersebut harus tercermin dalam metrik?
Ya, seharusnya begitu. Mengukur seberapa besar peningkatan pengalaman ini sulit dilakukan dalam skala besar, mengingat semua cara berbeda yang digunakan untuk menerapkan SPA di web saat ini. Sekarang kami memiliki solusi untuk masalah pengukuran, dan saat API baru ini digunakan, peningkatan apa pun dari beralih ke SPA akan tercermin dalam metrik.
Faktanya, industri performa web (termasuk Google) secara historis tidak menginvestasikan waktu dan upaya sebanyak itu untuk mengembangkan metrik yang berfokus pada pengguna untuk performa pasca-pemuatan halaman seperti yang dilakukan untuk pemuatan halaman itu sendiri. Hal ini bukan karena performa pasca-pemuatan tidak penting, tetapi karena UX dan interaksi pasca-pemuatan jauh lebih beragam dan kurang terdefinisi dengan baik—sehingga sulit untuk mendesain metriknya.
Namun, meskipun kini kita memiliki lebih banyak metrik pasca-pemuatan untuk mengukur performa SPA, kita tidak boleh mengabaikan pengalaman pemuatan hanya karena pengalaman pasca-pemuatan menjadi lebih baik.
Salah satu tujuan inisiatif Web Vitals adalah untuk mempromosikan dan mendorong pengalaman pengguna yang baik di sebanyak mungkin aspek pemuatan dan penggunaan halaman web. Kami tidak ingin mendorong skenario di mana pengalaman buruk dibenarkan jika Anda dapat memiliki cukup banyak pengalaman baik untuk mengimbanginya. Pengguna ingin halaman dimuat dengan cepat dan bertransisi ke konten baru dengan cepat, dan kami telah mencoba mendesain metrik yang mendukung jenis pengalaman tersebut.
Kami mengalihkan situs kami dari MPA ke SPA dan skor kami menurun. Apakah hal ini wajar?
Tergantung. Ada sejumlah alasan mengapa skor Anda dapat berubah setelah migrasi arsitektur besar, tetapi penurunan jumlah pemuatan cache hangat dapat menyebabkan sebagian perubahan tersebut.
Cara cepat untuk memeriksa adalah dengan menguji versi MPA dan SPA dari salah satu halaman landing Anda dengan Lighthouse. Jika skor Lighthouse lebih rendah pada salah satu metrik Core Web Vitals untuk versi SPA, kemungkinan pengalaman pemuatan menjadi lebih buruk setelah update.
Haruskah saya mengalihkan situs dari SPA ke MPA agar mendapatkan skor yang lebih baik di Core Web Vitals?
Mungkin tidak. Anda hanya boleh beralih dari SPA ke MPA jika Anda tidak puas dengan stack SPA dan Anda memiliki alasan untuk meyakini bahwa MPA akan memberikan pengalaman pengguna yang lebih baik.
Dengan pekerjaan navigasi ringan, kami yakin telah mengatasi masalah pengukuran, sehingga berpindah hanya karena alasan tersebut tidak masuk akal.
Namun, jika Anda memiliki alasan untuk menunjukkan bahwa performa akan meningkat, bukan hanya pengukuran yang meningkat, maka hal itu dapat menjadi alasan untuk beralih dari SPA ke MPA (atau sebaliknya).
Jika skor Core Web Vitals hanya dilaporkan untuk halaman landing SPA, bagaimana cara men-debug masalah yang terjadi di "halaman" setelah transisi rute?
Alat Google yang melaporkan data kolom untuk metrik Core Web Vitals (seperti Search Console dan PageSpeed Insights) mendapatkan datanya dari Chrome User Experience Report (CrUX). CrUX menggabungkan data berdasarkan asal atau URL halaman (yaitu, URL halaman pada waktu pemuatan).
Kami sedang berupaya agar CrUX dapat menyertakan data menurut rute SPA dalam data gabungannya. Namun, sebagai pemilik situs, Anda kini dapat menggunakan API baru untuk mengukur Core Web Vitals menurut rute SPA sebelum perubahan ini untuk memahami bagaimana skor Anda dapat berubah.
Untuk mengetahui detail dan praktik terbaik selengkapnya tentang hal ini, lihat: Mengukur navigasi ringan.
Apa yang dilakukan Google untuk memastikan MPA tidak memiliki keuntungan yang tidak adil dibandingkan dengan SPA?
Seperti yang disebutkan sebelumnya, dengan adanya pekerjaan navigasi ringan, kami yakin bahwa pekerjaan yang telah kami lakukan sekarang berarti tidak ada kerugian bagi SPA dalam hal ini, meskipun integrasi penuh di semua alat dan solusi pelaporan akan memerlukan waktu.
Menilai kunjungan halaman lintas origin dan origin yang sama secara terpisah
Saat ini, metrik Core Web Vitals menggabungkan semua kunjungan halaman ke dalam satu bucket—metrik ini tidak membedakan antara kunjungan baru dan pengunjung yang kembali atau halaman landing dan halaman checkout atau jenis penggabungan lainnya yang status cache-nya dapat memengaruhi performa.
Salah satu cara untuk menormalisasi perbedaan antara performa SPA dan MPA adalah dengan menerapkan bobot yang berbeda untuk berbagai jenis kunjungan, bahkan mungkin dengan rekomendasi nilai minimumyang sama sekali berbeda.
Meskipun kami ingin memberikan penghargaan untuk penerapan cache yang efektif, kami tidak ingin navigasi intra-situs yang cepat dapat menutupi pemuatan halaman landing yang lambat. Kami juga tidak ingin memberi insentif kepada situs untuk memecah halaman panjang menjadi kumpulan halaman yang lebih pendek hanya demi meningkatkan skor metrik.
Dengan menilai kunjungan halaman lintas origin dan origin yang sama secara terpisah, kami dapat membantu memastikan bahwa kedua jenis pengalaman tersebut penting tanpa membiarkan popularitas relatif satu jenis di situs tertentu memengaruhi distribusi metrik tertentu.
Kesimpulan
Google sangat berkomitmen untuk meningkatkan metrik Web Vitals, dan memastikan metrik tersebut mengukur dan mendorong pengalaman berkualitas tinggi yang penting bagi pengguna. Namun demikian, kami mengakui bahwa celah pengukuran masih ada hingga saat ini. Metrik kini dapat mencakup transisi rute SPA yang mengatasi salah satu kesenjangan utama.
Kami juga yakin bahwa API baru ini (terutama InteractionContentfulPaint) memiliki kegunaan dan potensi manfaat lebih lanjut di luar pengukuran Core Web Vitals untuk navigasi ringan. Kami sangat senang untuk terus mengembangkan fitur ini sekarang setelah alasan utama pengenalannya telah diatasi.
Semoga postingan ini telah membantu menjelaskan subjek yang kompleks dan bernuansa ini. Seperti biasa, jika ada masukan tentang metrik Vitals Web saat ini atau mendatang, kirim email ke web-vitals-feedback@googlegroups.com.