Jawaban atas pertanyaan umum tentang SPA, Data Web Inti, dan rencana Google untuk mengatasi batasan pengukuran saat ini.
Sejak pertama kali memperkenalkan inisiatif Web Vitals pada Mei 2 2020, kami di tim Chrome telah menerima banyak pertanyaan dan masukan bagus tentang program ini.
Mungkin topik yang paling sering kami terima pertanyaannya, yang juga mungkin merupakan pertanyaan tersulit untuk dijawab, adalah cara mengukur Core Web Vitals di aplikasi web satu halaman (SPA), serta pengaruh arsitektur SPA terhadap skor Core Web Vitals.
Pertanyaan ini sulit dijawab karena masalahnya cukup rumit. Jadi, dalam postingan ini, kami akan berusaha sebaik mungkin untuk menjawab pertanyaan yang paling umum, dengan memberikan detail dan konteks sebanyak mungkin.
Namun, sebelum membahas detailnya, penting untuk menyatakan bahwa Google tidak memiliki preferensi apa pun terkait arsitektur atau teknologi yang digunakan untuk membuat situs. Kami yakin bahwa SPA dan aplikasi multi-halaman (MPA) mampu memberikan pengalaman berkualitas tinggi kepada pengguna, dan tujuan kami dengan inisiatif Data Web adalah untuk memberikan metrik yang mengukur pengalaman secara independen dari teknologi. Meskipun saat ini hal ini tidak dapat dilakukan dalam setiap kasus (karena batasan di platform web), kami secara aktif berupaya menutup kesenjangan tersebut.
Pertanyaan umum (FAQ)
Apakah metrik Core Web Vitals menyertakan transisi rute SPA?
Tidak. Setiap metrik Data Web Inti diukur relatif terhadap navigasi halaman tingkat atas saat ini. Jika halaman memuat konten baru secara dinamis dan memperbarui URL halaman di kolom URL, hal ini 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.
Dapatkah metrik Core Web Vitals memperlakukan perubahan rute SPA sama seperti pemuatan halaman tradisional?
Sayangnya, tidak. Belum.
Saat ini, tidak ada cara standar untuk mem-build SPA, dan bahkan di antara library SPA dan pemilihan rute 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 lainnya tidak memperbarui URL sama sekali).
- Beberapa SPA memuat konten, lalu memperbarui URL, sedangkan yang lain memperbarui URL sebelum memuat konten.
- Beberapa SPA memuat konten sekaligus, secara sinkron, dalam satu tugas JavaScript, sedangkan yang lain mentransisikan 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 di awal sehingga perubahan rute dimuat langsung 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 "sebenarnya" dengan andal dari semua perubahan URL lainnya—serta sinyal yang jelas yang menandai awal dan akhir transisi tersebut—melaporkan metrik Data Web Inti dalam kasus ini akan mengaburkan data dan membuatnya kurang berguna atau tidak mewakili pengalaman pengguna sebenarnya di situs.
Apakah SPA lebih sulit mendapatkan hasil yang baik pada Core Web Vitals daripada MPA?
Tidak ada hal yang melekat dalam arsitektur SPA yang akan mencegah halaman di SPA dimuat dengan cepat—dan mendapatkan skor yang sama baik di semua metrik Data Web Inti—seperti halaman serupa di MPA.
Namun, MPA yang dioptimalkan dengan benar memiliki beberapa keunggulan dalam memenuhi nilai minimum Core Web Vitals yang saat ini tidak dimiliki SPA. Alasannya adalah 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 akhirnya 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 cache sub-resource yang dioptimalkan untuk memastikan pemuatan halaman dengan origin yang sama memang lebih cepat daripada pemuatan halaman lintas origin pada persentil ke-75.
- Pengguna yang mengunjungi MPA harus mengunjungi beberapa halaman agar situs tersebut menerima manfaat penyimpanan dalam cache yang menghasilkan pemuatan halaman yang lebih cepat.
Karena penilaian Data Web Inti 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 berada dalam nilai minimum yang direkomendasikan.
Perhatikan bahwa hal penting yang perlu dipertimbangkan saat membandingkan skor Data Web Inti adalah cara data digabungkan, yaitu apakah set data dalam distribusi menyertakan semua halaman dari situs atau origin Anda, atau hanya pemuatan halaman untuk URL halaman tertentu.
Saat menggabungkan skor semua halaman di origin, setiap halaman yang cepat dapat meningkatkan persentil ke-75 untuk origin secara keseluruhan. Namun, saat menggabungkan berdasarkan halaman individual, skor satu halaman tidak akan memengaruhi skor halaman berikutnya. Dengan kata lain, saat menggabungkan skor MPA berdasarkan 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 setiap URL halaman dan seluruh origin.
Cara lain arsitektur SPA dapat memengaruhi skor Data Web Inti 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 seiring waktu dapat lebih buruk di SPA daripada MPA.
Pada April 2021, kami mengumumkan perubahan pada metrik CLS yang sebagian mengatasi masalah ini. Sebelumnya, CLS akan terakumulasi selama seluruh siklus proses halaman, sedangkan sekarang hanya terakumulasi selama periode waktu tertentu—pada dasarnya adalah lonjakan pergeseran tata letak terburuk di halaman tertentu.
Namun, meskipun dengan definisi CLS baru, SPA masih dirugikan karena nilai CLS tidak "direset" setelah transisi rute seperti halnya dengan pemuatan halaman penuh di MPA. Hal ini juga dapat menyebabkan kebingungan karena pergeseran tata letak yang terjadi setelah transisi rute akan diatribusikan ke URL halaman saat dimuat, bukan URL di kolom URL pada saat pergeseran (detail selengkapnya di bawah).
Jika arsitektur SPA meningkatkan pengalaman pengguna, bukankah peningkatan tersebut akan tercermin dalam metrik?
Ya, seharusnya. Meskipun seperti yang disebutkan sebelumnya, mengukur seberapa banyak pengalaman telah meningkat sulit dilakukan dalam skala besar, mengingat semua cara yang berbeda untuk menerapkan SPA di web saat ini.
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-muat halaman seperti yang dilakukan untuk pemuatan halaman itu sendiri. Hal ini bukan karena performa post-load tidak penting, tetapi karena UX dan interaksi post-load jauh lebih beragam dan kurang jelas—sehingga sulit untuk mendesain metrik untuk mereka.
Namun, meskipun kita memiliki metrik pasca-muat yang ditentukan dengan baik untuk mengukur performa SPA, kita tidak ingin mengabaikan pengalaman pemuatan hanya karena pengalaman pasca-muat menjadi lebih baik.
Salah satu sasaran inisiatif Data Web adalah mempromosikan dan memberikan insentif untuk pengalaman pengguna yang baik di sebanyak mungkin aspek pemuatan dan penggunaan halaman web. Kami tidak ingin mendorong skenario yang membenarkan pengalaman buruk jika Anda dapat memiliki cukup 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.
Jadi, meskipun versi MPA situs mungkin memiliki performa yang lebih baik pada metrik Core Web Vitals pada persentil ke-75 daripada versi SPA situs yang sama persisnya, versi SPA harus tetap berusaha memenuhi nilai minimum "baik". Jika versi SPA tidak memenuhi nilai minimum "baik" bagi sebagian besar pengguna, pengalaman muat awal mungkin masih tidak dianggap baik—meskipun pengalaman navigasi dalam halaman berikutnya sangat baik.
Di masa mendatang, kami berencana untuk mengembangkan metrik yang mendorong pengalaman post-load yang luar biasa, dan kami yakin ini adalah jalur terbaik untuk memberikan insentif kepada SPA berkualitas tinggi dengan cara yang tidak mengorbankan pengalaman pemuatan awal. Kami telah menyediakan metrik baru bernama Interaction to Next Paint (INP) yang mengukur latensi interaksi di seluruh siklus proses halaman, dan kami juga secara aktif mengerjakan metrik pasca-muat lainnya, termasuk metrik yang mengukur transisi rute SPA (lihat di bawah).
Kami mengalihkan situs dari MPA ke SPA dan skor kami mengalami regresi. Apakah hal itu sudah diperkirakan?
Tergantung. Ada sejumlah alasan mengapa skor Anda dapat berubah setelah migrasi arsitektur utama, tetapi penurunan jumlah pemuatan cache hangat dapat menjelaskan sebagian perubahan tersebut.
Cara cepat untuk memeriksanya 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 memang menjadi lebih buruk setelah update.
Apakah saya harus mengalihkan situs dari SPA ke MPA untuk mendapatkan skor yang lebih baik di Core Web Vitals?
Mungkin tidak. Anda hanya boleh beralih dari SPA ke MPA jika tidak puas dengan stack SPA dan Anda memiliki alasan untuk meyakini bahwa MPA akan memberikan pengalaman pengguna yang lebih baik.
Seiring waktu, saat metrik Core Web Vitals meningkat dan mencakup lebih banyak pengalaman penjelajahan lengkap, tim dengan SPA yang dibuat dengan baik dan memberikan UX yang luar biasa akan menemukan bahwa skor Core Web Vitals mereka mencerminkan hal tersebut.
Jika skor Data Web Inti 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 Laporan Pengalaman Pengguna Chrome (CrUX). Selain itu, CrUX menggabungkan data berdasarkan asal atau URL halaman (yaitu, URL halaman pada waktu pemuatan).
Karena semua alasan yang telah tercantum di atas, CrUX tidak dapat menggabungkan data menurut rute SPA. Namun, sebagai pemilik situs yang memahami arsitektur Anda sendiri, Anda dapat mengukurnya sendiri, dan banyak alat analisis memungkinkan Anda memberikan sinyal saat perubahan rute SPA terjadi dan alat tersebut akan memperbarui data pengukuran Anda.
Saat mengukur metrik Data Web dengan alat analisis, pastikan Anda mengukur URL rute saat ini serta URL halaman asli. Dengan begitu, Anda dapat men-debug setiap masalah yang terjadi selama siklus proses halaman serta menggabungkannya berdasarkan URL halaman asli untuk mencocokkan cara alat Google mengukur dan melaporkan metrik.
Untuk mengetahui detail selengkapnya dan praktik terbaik tentang topik ini, lihat: Men-debug performa di lapangan.
Apa yang dilakukan Google untuk memastikan MPA tidak memiliki keunggulan yang tidak adil dibandingkan dengan SPA?
Seperti yang disebutkan di atas, dalam beberapa kasus, MPA yang dioptimalkan dengan benar dapat melaporkan skor Web Vitals yang lebih baik pada persentil ke-75 karena kemungkinan akan memiliki persentase kunjungan halaman yang di-cache lebih tinggi. Sebaliknya, peningkatan nyata pada pengalaman pengguna di SPA yang dioptimalkan dengan benar saat ini tidak dicatat oleh metrik Core Web Vitals.
Di Google, kami menyadari bahwa hal ini menciptakan insentif yang tidak sepenuhnya selaras dengan sasaran inisiatif Data Web, dan kami secara aktif mencari cara untuk memperbaikinya. Saat ini, kami sedang mempelajari dua solusi potensial, satu solusi jangka pendek dan satu solusi jangka panjang:
- Menilai kunjungan halaman lintas origin dan origin yang sama secara terpisah.
- Mendesain API baru yang memungkinkan pengukuran SPA yang lebih baik.
Menilai kunjungan halaman lintas origin dan origin yang sama secara terpisah
Saat ini, metrik Data Web Inti menggabungkan semua kunjungan halaman ke dalam satu bucket—metrik ini tidak membedakan antara kunjungan baru dan kunjungan kembali atau halaman landing dan halaman checkout, atau jenis agregasi 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 minimum yang sama sekali berbeda.
Meskipun kami ingin memberikan reward atas penerapan cache yang efektif, kami tidak ingin navigasi intra-situs yang cepat dapat menutupi pemuatan halaman landing yang lambat. Kami juga tidak ingin memberikan insentif kepada situs untuk memecah halaman panjang menjadi kumpulan halaman yang lebih pendek hanya untuk meningkatkan skor metrik.
Dengan menilai kunjungan halaman lintas origin dan halaman dengan origin yang sama secara terpisah, kami dapat membantu memastikan bahwa kedua jenis pengalaman tersebut penting tanpa membiarkan popularitas relatif dari satu jenis di situs tertentu mendistorsi distribusi metrik tertentu.
Mendesain API baru yang memungkinkan pengukuran SPA yang lebih baik
Solusi lain yang sedang aktif dikerjakan (secara paralel dengan solusi di atas) adalah App History API baru, yang akan membantu menstandarkan pola SPA saat ini dan mempermudah pengukuran serta pemahaman penggunaan SPA dalam skala besar.
App History API memperkenalkan peristiwa
navigate baru, yang
memiliki dua fitur utama khusus untuk pengukuran SPA:
- Flag
userInitiated, yang hanya akan ditetapkan ke true jika navigasi dimulai melalui klik link, pengiriman formulir, atau UI kembali atau maju browser. - Metode
transitionWhile()yang menggunakan promise yang memungkinkan developer memberikan sinyal saat pekerjaan yang mereka mulai untuk melakukan navigasi selesai.
Flag userInitiated dapat digunakan untuk menentukan titik awal semantik untuk
transisi rute SPA, yang menunjukkan intent pengguna yang jelas. Penyelesaian promise transitionWhile()
dapat membantu browser mengaitkan cat dengan transisi rute
tertentu, sehingga browser dapat menentukan largest contentful paint
yang terkait dengan transisi tersebut.
Berdasarkan ide yang disajikan di bagian sebelumnya, Anda mungkin dapat menggabungkan waktu transisi rute SPA ke dalam bucket yang sama dengan muat halaman origin yang sama di MPA. Hal ini menarik karena memungkinkan situs yang bermigrasi dari MPA ke SPA untuk benar-benar membandingkan performa sebelum dan sesudahnya.
Tentu saja, diperlukan lebih banyak riset sebelum kita mengetahui apakah kita dapat membuat determinasi ini secara akurat. Jika Anda memiliki saran atau masukan tentang proposal ini, kirim email ke web-vitals-feedback@googlegroups.com.
Poin penutup
Google sangat berkomitmen untuk meningkatkan metrik Data Web, dan memastikan metrik tersebut mengukur serta memberikan insentif untuk pengalaman berkualitas tinggi yang penting bagi pengguna. Meskipun demikian, kami mengakui bahwa saat ini ada kesenjangan pengukuran. Metrik saat ini tidak mencakup setiap aspek pengalaman pengguna, tetapi kami secara aktif berupaya untuk menutup kesenjangan ini.
Meskipun ada keterbatasan saat ini, kami yakin bahwa area yang diukur oleh metrik yang ada sangat penting bagi kesehatan dan kesuksesan web, dan sejauh situs (terlepas dari arsitekturnya) tidak memenuhi nilai minimum yang direkomendasikan, kami yakin ada ruang untuk peningkatan.
Semoga postingan ini telah membantu menjelaskan subjek yang kompleks dan rumit ini. Seperti biasa, jika Anda memiliki masukan tentang metrik Data Web saat ini atau mendatang, kirim email ke web-vitals-feedback@googlegroups.com.