Jawaban atas pertanyaan umum tentang SPA, Core Web Vitals, dan rencana Google untuk mengatasi batasan pengukuran saat ini.
Sejak pertama kali memperkenalkan inisiatif Data Web pada Mei 2020, kami tim Chrome telah menerima banyak pertanyaan dan masukan bagus tentang program ini.
Mungkin topik yang kami terima paling banyak pertanyaannya, yang juga mungkin pertanyaan yang paling sulit untuk dijawab, adalah cara mengukur Core Web Vitals dalam aplikasi web satu halaman (SPA), serta pengaruh arsitektur SPA terhadap skor Core Web Vitals.
Pertanyaan-pertanyaan ini sulit untuk dijawab karena masalahnya cukup rumit, jadi postingan ini akan berusaha sebaik mungkin untuk menjawab pertanyaan yang paling umum, memberikan detail dan konteks sebanyak yang kami bisa.
Namun, sebelum membahas secara spesifik, penting untuk dinyatakan bahwa Google melakukan tidak memiliki preferensi dalam hal arsitektur atau teknologi apa yang digunakan untuk membangun situs Anda. Kami meyakini bahwa SPA dan aplikasi multi-halaman (MPA) mampu dalam memberikan pengalaman berkualitas tinggi kepada pengguna, dan niat kami dengan Web Inisiatif Vitals adalah untuk memberikan metrik yang mengukur pengalaman secara independen yang lebih baik. Meskipun hal ini tidak mungkin dilakukan dalam setiap kasus saat ini (karena keterbatasan di platform web), kami secara aktif berupaya untuk kesenjangan.
Pertanyaan umum (FAQ)
Apakah metrik Core Web Vitals menyertakan transisi rute SPA?
Tidak. Setiap metrik Core Web Vitals diukur secara relatif terhadap data navigasi halaman tingkat atas. Jika halaman secara dinamis memuat dan memperbarui URL halaman di kolom URL, URL tidak akan pada cara pengukuran metrik Core Web Vitals. Nilai metrik bukan direset, dan URL yang terkait dengan setiap pengukuran metrik adalah URL yang membuka halaman yang memulai pemuatan halaman.
Dapatkah metrik Core Web Vitals menangani perubahan rute SPA sama seperti pemuatan halaman biasa?
Sayangnya, tidak. Belum.
Tidak ada cara terstandardisasi untuk membangun SPA saat ini, dan bahkan di antara para SPA dan pustaka {i>routing<i} yang populer, pengalaman pengguna bisa sangat berbeda dari satu aplikasi ke aplikasi lainnya:
- Beberapa Aplikasi Web Satu Halaman memperbarui URL hanya saat memuat "halaman penuh" baru konten, sedangkan situs lain memperbarui URL untuk perubahan konten kecil atau bahkan hanya status UI perubahan.
- Beberapa Aplikasi Web Satu Halaman memperbarui URL menggunakan History API, sedangkan yang lain menggunakan hash perubahan untuk mendukung browser lama (dan yang lainnya tidak memperbarui URL ).
- Beberapa Aplikasi Web Satu Halaman memuat konten, lalu memperbarui URL, sedangkan yang lainnya memperbarui URL sebelum memuat konten.
- Beberapa SPA memuat konten sekaligus, secara sinkron, dalam satu JavaScript tugas sementara yang lain mentransisikan konten secara asinkron, di beberapa tugas (tanpa peristiwa akhir transisi yang jelas).
- Beberapa Aplikasi Web Satu Halaman selalu memuat konten dari jaringan, sedangkan yang lainnya melakukan pramuat semuanya konten di awal sehingga perubahan rute itu dimuat dari memori secara instan.
Perbedaan ini menentukan dan mengidentifikasi apa yang dimaksud dengan rute SPA perubahan, atau bahkan SPA itu sendiri, sangat sulit dilakukan dalam skala besar.
Dalam beberapa kasus, perubahan rute SPA secara logis identik dengan pemuatan laman MPA, Oleh karena itu, sebaiknya metrik Core Web Vitals yang ada dapat diterapkan.
Namun, tanpa heuristik yang solid untuk mengidentifikasi "nyata" secara andal perubahan rute dari semua perubahan URL lainnya—serta sinyal yang jelas yang menandai awal dan akhir transisi tersebut—pelaporan Data Web Inti pelaporan dalam kasus ini akan berlumpur data dan membuatnya kurang berguna atau tidak mewakili pengalaman pengguna yang sebenarnya di situs.
Apakah SPA lebih sulit melakukannya dengan baik di Core Web Vitals daripada MPA?
Tidak ada yang melekat dalam arsitektur SPA yang akan menghalangi halaman di SPA agar tidak memuat dengan cepat—dan mencetak skor sama baiknya di semua Metrik Web Vitals—sebagai halaman serupa dalam MPA.
Namun, MPA yang dioptimalkan dengan benar memiliki beberapa keuntungan dalam memenuhi Nilai minimum vital yang saat ini tidak dapat dilakukan SPA. Alasannya adalah karena dengan MPA arsitektur, setiap "halaman" dimuat sebagai navigasi halaman penuh (bukan mengambil konten secara dinamis dan memasukkannya ke halaman yang ada), yang berarti pengguna yang mengunjungi MPA cenderung memuat lebih dari satu halaman dari yang berarti bahwa semakin besar persentase distribusi dari semua pemuatan halaman untuk MPA akan melibatkan beberapa atau semua sub-sumber daya di-cache.
Meskipun demikian, agar MPA berperforma lebih baik pada metrik Core Web Vitals daripada SPA memerlukan beberapa hal berikut:
- MPA perlu memiliki sub-resource caching yang dioptimalkan untuk memastikan pemuatan halaman origin yang sama memang lebih cepat daripada pemuatan halaman lintas origin di Persentil ke-75.
- Pengguna yang mengunjungi MPA perlu mengunjungi beberapa halaman agar situs menerima manfaat penyimpanan dalam cache yang menghasilkan pemuatan halaman lebih cepat.
Sejak penilaian Core Web Vitals mempertimbangkan persentil halaman kunjungan halaman, lebih banyak kunjungan halaman yang berperforma baik dalam set data akan meningkat kemungkinan bahwa kunjungan pada persentil ke-75 dari distribusi akan dalam ambang batas yang direkomendasikan.
Perhatikan bahwa hal penting yang perlu dipertimbangkan saat membandingkan skor Core Web Vitals adalah bagaimana data diagregasikan—yaitu, apakah {i>dataset<i} dalam distribusi berisi semua halaman dari situs atau asal Anda, atau hanya pemuatan halaman untuk URL halaman tersebut.
Saat menggabungkan skor dari semua halaman dalam sebuah origin, tiap halaman cepat dapat meningkatkan persentil ke-75 untuk origin secara keseluruhan. Namun, ketika menggabungkan oleh setiap halaman, skor dari satu halaman tidak akan memengaruhi skor berikutnya. Dengan kata lain, saat menggabungkan skor MPA berdasarkan halaman, pemuatan yang terlihat di halaman checkout tidak akan meningkatkan skor pemuatan awal yang lambat pemuatan yang dialami di landing situs halaman.
Anda dapat memeriksa skor situs untuk berbagai metode agregasi menggunakan PageSpeed Insights atau Laporan Pengalaman Pengguna Chrome API, yang melaporkan skor untuk masing-masing URL halaman dan seluruh origin.
Cara lain arsitektur SPA dapat memengaruhi skor Core Web Vitals adalah metrik yang mempertimbangkan masa aktif halaman secara penuh. Karena pengguna mengunjungi SPA cenderung berada di "halaman" yang sama untuk seluruh sesi, metrik yang mengakumulasi dari waktu ke waktu bisa lebih keras terhadap SPA daripada MPA.
Pada April 2021, kami mengumumkan perubahan pada metrik CLS yang mengatasi sebagian masalah ini. Sebelumnya, CLS akan terakumulasi selama seluruh masa aktif halaman, sedangkan kini hanya terakumulasi pada periode tertentu waktu — pada dasarnya burst pergeseran tata letak terburuk di halaman tertentu.
Namun, meskipun dengan definisi CLS yang baru, SPA masih kurang diuntungkan karena nilai CLS tidak "direset" setelah transisi rute seperti yang dengan pemuatan halaman penuh dalam MPA. Hal ini juga dapat menyebabkan kebingungan karena tata letak pergeseran yang terjadi setelah transisi rute akan diatribusikan ke URL halaman saat dimuat, bukan URL di kolom URL pada saat shift (detail selengkapnya di bawah).
Jika arsitektur SPA meningkatkan pengalaman pengguna, bukankah peningkatan tersebut seharusnya tercermin dalam metrik?
Ya, seharusnya. Meskipun seperti yang disebutkan sebelumnya, mengukur berapa banyak telah meningkat sulit dilakukan dalam skala besar, mengingat perbedaan cara penerapan SPA di web saat ini.
Yang benar adalah industri performa web (termasuk Google) secara historis belum menginvestasikan hampir sebanyak mungkin waktu dan upaya untuk mengembangkan yang berpusat pada pengguna metrik untuk performa pasca-pemuatan seperti saat halaman dimuat itu sendiri. Ini bukan karena pasca-pemuatan performa tidak penting, itu karena UX dan interaksi pasca-pemuatan begitu jauh lebih bervariasi dan kurang terdefinisi dengan baik—sehingga sulit untuk merancang metrik untuk mereka.
Namun, meskipun kita sudah memiliki metrik pasca-pemuatan yang ditentukan dengan baik untuk mengukur SPA performa, kita tidak ingin mengabaikan pengalaman pemuatan hanya karena pengalaman pasca-muat menjadi lebih baik.
Salah satu sasaran inisiatif Data Web adalah untuk mempromosikan dan memberikan insentif pengalaman pengguna di sebanyak mungkin aspek pemuatan dan penggunaan halaman web sebaik mungkin. Kami tidak ingin mendorong skenario dengan pengalaman buruk dibenarkan jika Anda dapat memiliki pengalaman yang cukup baik untuk menutupinya. Pengguna ingin halaman dimuat dengan cepat dan bertransisi ke konten baru dengan cepat, dan kami telah mencoba metrik desain yang mendukung jenis pengalaman tersebut.
Jadi, meskipun benar bahwa versi MPA dari sebuah situs mungkin berjalan lebih baik di Metrik vital pada persentil ke-75 daripada versi SPA yang sama persis situs web tersebut, versi SPA harus tetap berupaya untuk memenuhi nilai minimum. Jika Versi SPA tidak memenuhi syarat "baik" minimum untuk sebagian besar pengguna, maka pengalaman pemuatan Anda mungkin masih belum dianggap baik—bahkan jika berikutnya, pengalaman navigasi dalam halaman sangat baik.
Ke depannya, kami berencana mengembangkan metrik yang mendorong performa pasca-pemuatan yang bagus pengalaman, dan kami yakin ini adalah cara terbaik untuk memberikan insentif SPA dengan cara yang tidak mengganggu pengalaman pemuatan awal. Kita memiliki sudah mengirimkan metrik baru bernama Interaction to Next Paint (INP) yang mengukur latensi interaksi di seluruh siklus proses halaman, dan kami aktif mengerjakan juga metrik pasca-pemuatan, termasuk metrik yang mengukur transisi rute SPA (lihat di bawah).
Kami mengalihkan situs dari MPA ke SPA dan skor kami naik. Apakah itu yang diharapkan?
Tergantung. Ada sejumlah alasan mengapa skor Anda dapat berubah setelah migrasi arsitektur besar, tetapi penurunan jumlah pemuatan warm cache dapat memperhitungkan beberapa perubahan.
Cara cepat untuk memeriksanya adalah dengan menguji versi MPA dan SPA dari salah satu halaman landing dengan Mercusuar. Jika Skor Lighthouse lebih rendah pada metrik Core Web Vitals untuk SPA maka kemungkinan pengalaman pemuatan menjadi lebih buruk setelah memperbarui.
Haruskah saya beralih dari SPA ke MPA untuk mendapatkan skor yang lebih baik di Core Web Vitals?
Mungkin tidak. Sebaiknya Anda hanya beralih dari SPA ke MPA jika Anda tidak puas dengan stack SPA dan Anda memiliki alasan untuk meyakini bahwa MPA akan memberikan {i>user experience<i}.
Seiring waktu, seiring peningkatan metrik Core Web Vitals dan mencakup lebih banyak pengalaman penjelajahan, tim dengan SPA yang dibangun dengan baik yang memberikan UX yang baik harus melihat skor Core Web Vitals mereka mencerminkan hal tersebut.
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 Penelusuran Konsol dan PageSpeed Insights) mendapatkan data mereka dari Pengalaman Pengguna Chrome Laporkan (CrUX). Dan CrUX menggabungkan data berdasarkan asal atau URL halaman (yaitu, URL halaman pada waktu pemuatan).
Untuk semua alasan yang sudah tercantum di atas, CrUX tidak dapat menggabungkan data dengan rute SPA. Namun, sebagai pemilik situs yang terbiasa dengan arsitektur Anda sendiri, Anda dapat mengukurnya sendiri, dan banyak alat analitik memungkinkan Anda untuk saat terjadi perubahan rute SPA dan perubahan tersebut memperbarui pengukuran Anda data sebagaimana mestinya.
Saat mengukur metrik Data Web dengan alat analisis, pastikan Anda mengukur URL rute saat ini serta URL halaman asli. Hal ini akan memungkinkan Anda men-debug masalah individual yang terjadi di seluruh halaman serta digabungkan berdasarkan URL halaman asli untuk menyesuaikan dengan performa mengukur dan melaporkan metrik.
Untuk detail dan praktik terbaik selengkapnya tentang topik ini, lihat: Men-debug performa di kolom.
Apa yang dilakukan Google untuk memastikan MPA tidak memiliki keuntungan yang tidak adil dibandingkan dengan SAA?
Seperti disebutkan di atas, MPA yang dioptimalkan dengan tepat dapat, dalam beberapa kasus, melaporkan Skor Web Vitals pada persentil ke-75 karena kemungkinan besar memiliki persentase kunjungan halaman yang di-cache lebih tinggi. Sebaliknya, peningkatan nyata pada pengalaman pengguna dalam SPA yang dioptimalkan dengan benar saat ini tidak dicatat oleh metrik Core Web Vitals mana pun.
Di Google, kami menyadari bahwa hal ini menimbulkan insentif yang tidak sepenuhnya selaras dengan sasaran inisiatif Data Web, dan kami secara aktif mencari cara untuk memperbaiki hal ini. Saat ini, kami sedang mempertimbangkan dua solusi potensial, yaitu satu solusi jangka pendek dan satu jangka panjang:
- Menilai kunjungan halaman lintas origin dan origin yang sama secara terpisah.
- Desain API baru yang memungkinkan pengukuran SPA yang lebih baik.
Menilai kunjungan halaman lintas origin dan halaman asal yang sama secara terpisah
Saat ini, metrik Core Web Vitals menggabungkan semua kunjungan halaman menjadi satu bucket—tidak membedakan antara kunjungan baru atau kunjungan kembali atau landing halaman versus halaman checkout atau jenis agregasi lainnya dengan status cache dapat memengaruhi performa.
Salah satu cara untuk menormalkan perbedaan antara kinerja SPA dan MPA adalah dengan menerapkan pembobotan yang berbeda pada berbagai jenis kunjungan, bahkan mungkin nilai minimum yang benar-benar berbeda rekomendasi.
Meskipun kita ingin memberikan reward atas implementasi cache yang efektif, kita tidak ingin navigasi intra-situs yang cepat dapat menutupi halaman landing yang lambat memuat. Kami juga tidak ingin memberi insentif kepada situs untuk memecah halaman yang panjang menjadi kumpulan halaman yang lebih pendek hanya untuk meningkatkan skor metrik.
Dengan menilai kunjungan halaman lintas origin dan origin yang sama secara terpisah, kami dapat membantu memastikan kedua jenis pengalaman itu penting tanpa membiarkan popularitas suatu jenis di situs tertentu mendistorsi distribusi metrik.
Merancang API baru yang memungkinkan pengukuran SPA yang lebih baik
Solusi lain yang sedang dikerjakan secara aktif (selaras dengan hal di atas) adalah App History API baru, yang akan membantu menstandarkan pola SPA dan membuatnya lebih mudah untuk mengukur dan memahami penggunaan SPA dalam skala besar.
App History API memperkenalkan
Peristiwa navigate, yang
memiliki dua fitur utama khusus untuk pengukuran SPA:
- J
userInitiated, yang hanya akan disetel ke benar (true) jika navigasi dimulai melalui klik link, pengiriman formulir, atau UI kembali atau maju browser. - J
transitionWhile(), yang mengambil janji yang memungkinkan pengembang untuk memberi sinyal ketika pekerjaan yang mereka lakukan untuk melakukan navigasi selesai.
Flag userInitiated dapat digunakan untuk menentukan titik awal semantik untuk
transisi rute SPA, yang
menunjukkan maksud pengguna yang jelas. transitionWhile()
penyelesaian promise dapat membantu browser menghubungkan paint dengan rute tertentu
tertentu, sehingga alat ini dapat menentukan jenis konten
yang terkait dengan transisi tersebut.
Berlandaskan ide yang disajikan di bagian sebelumnya, bahkan mungkin agregasi waktu transisi rute SPA ke dalam bucket yang sama dengan pemuatan halaman origin yang sama dalam MPA. Ini menarik karena cara ini akan memungkinkan sebuah situs bermigrasi dari MPA ke SPA untuk benar-benar membandingkan gambar berikutnya.
Tentu saja, diperlukan lebih banyak penelitian sebelum kami tahu apakah kami dapat secara akurat membuat keputusan tersebut. Jika Anda memiliki saran atau masukan untuk proposal, silakan kirim email web-vitals-feedback@googlegroups.com.
Poin penutup
Google sangat berkomitmen untuk meningkatkan metrik Data Web, dan memastikan mereka mengukur dan memberikan insentif pengalaman berkualitas tinggi yang penting untuk pelanggan. Meskipun demikian, kami mengakui bahwa masih ada kesenjangan pengukuran saat ini. Tujuan saat ini tidak mencakup setiap aspek pengalaman pengguna, tetapi kami secara aktif berupaya untuk menutup kesenjangan ini.
Terlepas dari keterbatasan saat ini, kami percaya bahwa aspek yang didukung metrik yang ada sangat penting bagi kesehatan dan keberhasilan web, dan apabila bahwa situs (terlepas dari arsitektur) tidak memenuhi batas yang disarankan, kami yakin masih ada yang bisa ditingkatkan.
Saya harap postingan ini dapat membantu menjelaskan subjek yang kompleks dan rumit ini. Seperti biasa, jika Anda memiliki masukan tentang metrik Data Web saat ini atau di masa mendatang, tolong kirim email web-vitals-feedback@googlegroups.com.