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 di tim Chrome telah menerima banyak pertanyaan dan masukan bagus tentang program ini.
Mungkin topik yang paling banyak kami tanyakan, yang juga mungkin menjadi pertanyaan paling sulit untuk dijawab, adalah cara mengukur Data Web Inti dalam aplikasi web satu halaman (SPA), serta bagaimana arsitektur SPA memengaruhi skor Data Web Inti.
Pertanyaan ini sulit dijawab karena masalahnya cukup rumit, jadi dalam postingan ini, kami akan melakukan yang terbaik untuk menjawab pertanyaan paling umum, dengan memberikan detail dan konteks sebanyak mungkin.
Namun, sebelum membahas secara spesifik, penting untuk menyatakan bahwa Google tidak memiliki preferensi terkait arsitektur atau teknologi apa yang digunakan untuk membangun situs. Kami percaya bahwa aplikasi SPA dan multi-halaman (MPA) mampu memberikan pengalaman berkualitas tinggi kepada pengguna, dan tujuan kami dengan inisiatif Web Vitals adalah memberikan metrik yang mengukur pengalaman secara terpisah dari teknologi. Meskipun saat ini tidak semua dapat dilakukan (karena batasan di platform web), kami aktif berupaya menutup kesenjangan tersebut.
Pertanyaan umum (FAQ)
Apakah metrik Data Web Inti 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, cara tersebut tidak akan berpengaruh pada cara pengukuran metrik Data Web Inti. Nilai metrik tidak direset, dan URL yang terkait dengan setiap pengukuran metrik adalah URL yang dibuka pengguna yang memulai pemuatan halaman.
Dapatkah metrik Data Web Inti memperlakukan perubahan rute SPA sama seperti pemuatan halaman tradisional?
Sayangnya tidak. Belum.
Saat ini, tidak ada cara standar untuk membangun SPA, dan bahkan di antara SPA dan library perutean yang populer, pengalaman pengguna bisa sangat berbeda dari satu aplikasi ke aplikasi lainnya:
- Beberapa SPA memperbarui URL hanya 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, sementara yang lain menggunakan perubahan hash untuk mendukung browser lama (dan yang lainnya tidak memperbarui URL sama sekali).
- Beberapa SPA memuat konten, lalu memperbarui URL, sementara yang lain memperbarui URL sebelum memuat konten.
- Beberapa SPA memuat konten sekaligus, secara sinkron, dalam satu tugas JavaScript, sementara yang lain mentransisikan konten secara, secara asinkron, di beberapa tugas (tanpa peristiwa akhir transisi yang jelas).
- Beberapa SPA selalu memuat konten dari jaringan, sementara yang lain melakukan pramuat semua konten di awal sehingga perubahan rute dimuat langsung dari memori.
Perbedaan ini membuat penentuan dan identifikasi yang termasuk dalam 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 seperti ini, akan lebih baik jika metrik Data Web Inti yang ada dapat diterapkan.
Namun, tanpa heuristik yang solid untuk mengidentifikasi perubahan rute yang "nyata" secara andal dari semua perubahan URL lainnya—serta sinyal yang jelas yang menandai awal dan akhir transisi tersebut—pelaporan metrik Data Web Inti dalam kasus ini akan memperkeruh data dan membuatnya kurang berguna atau mewakili pengalaman pengguna yang sebenarnya di situs.
Apakah lebih sulit bagi SPA untuk bekerja dengan baik pada Data Web Inti daripada MPA?
Tidak ada yang melekat dalam arsitektur SPA yang akan mencegah halaman di SPA dimuat dengan cepat—dan mendapatkan skor yang sama baiknya pada semua metrik Data Web Inti—sebagai halaman serupa di MPA.
Namun, IKP yang dioptimalkan dengan baik memiliki beberapa keuntungan dalam memenuhi nilai minimum Vital Web Inti yang saat ini tidak dimiliki SPA. Alasannya karena dengan arsitektur MPA, setiap "halaman" dimuat sebagai navigasi satu halaman penuh (bukan mengambil konten secara dinamis dan memasukkannya ke halaman yang ada), sehingga pengguna yang mengunjungi MPA cenderung memuat lebih dari satu halaman dari situs, yang pada akhirnya berarti persentase distribusi yang lebih besar dari semua pemuatan halaman untuk MPA akan melibatkan sebagian atau semua sub-resource yang di-cache.
Memang, agar MPA berperforma lebih baik pada metrik Data Web Inti daripada SPA memerlukan beberapa hal berikut:
- 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 IKP harus mengunjungi beberapa halaman agar situs 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 bahwa kunjungan pada persentil ke-75 dari distribusi akan berada dalam batas 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 mencakup 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, ketika digabungkan berdasarkan halaman individual, skor satu halaman tidak akan memengaruhi skor halaman berikutnya. Dengan kata lain, saat menggabungkan skor MPA menurut halaman, pemuatan cache yang 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 API Laporan Pengalaman Pengguna Chrome, yang melaporkan skor untuk setiap URL halaman dan seluruh origin.
Cara lain yang dapat digunakan arsitektur SPA terhadap skor Data Web Inti adalah untuk metrik yang mempertimbangkan masa aktif halaman secara penuh. Karena pengguna yang mengunjungi SPA cenderung tetap berada di "halaman" yang sama untuk seluruh sesi, metrik yang terakumulasi dari waktu ke waktu dapat lebih kasar daripada MPA.
Pada April 2021, kami mengumumkan perubahan pada metrik CLS yang telah mengatasi sebagian masalah ini. Sebelumnya, CLS akan terakumulasi selama masa aktif halaman, sedangkan sekarang hanya terakumulasi selama jangka waktu tertentu—pada dasarnya burst pergeseran tata letak terburuk di halaman tertentu.
Namun, meskipun dengan definisi CLS baru, SPA masih tidak menguntungkan karena nilai CLS tidak "direset" setelah rute bertransisi seperti saat pemuatan halaman penuh dalam MPA. Hal ini juga dapat menyebabkan kebingungan karena pergeseran tata letak yang terjadi setelah transisi rute akan diatribusikan dengan URL halaman saat dimuat, bukan URL di kolom URL pada saat perpindahan (detail selengkapnya di bawah).
Jika arsitektur SPA meningkatkan pengalaman pengguna, bukankah peningkatan itu seharusnya tercermin dalam metrik?
Ya, seharusnya begitu. Meskipun disebutkan sebelumnya, mengukur seberapa banyak pengalaman yang telah ditingkatkan sulit dilakukan dalam skala besar, mengingat berbagai cara penerapan SPA di web saat ini.
Faktanya, industri performa web (termasuk Google) secara historis belum menginvestasikan hampir banyak waktu dan upaya untuk mengembangkan metrik yang berfokus pada pengguna untuk performa pasca-pemuatan halaman seperti pada pemuatan halaman itu sendiri. Hal ini bukan karena performa pasca-pemuatan tidak penting, melainkan karena UX dan interaksi pasca-pemuatan sangat jauh lebih bervariasi dan kurang terdefinisi dengan baik sehingga sulit untuk mendesain metrik untuk mereka.
Namun, meskipun kita memiliki metrik pasca-pemuatan yang ditentukan dengan baik untuk mengukur performa SPA, kita sebaiknya tidak mengabaikan pengalaman pemuatan hanya karena pengalaman pascapemuatan menjadi lebih baik.
Salah satu tujuan inisiatif Data Web adalah untuk mempromosikan dan memberikan insentif pengalaman pengguna yang baik di berbagai aspek pemuatan dan penggunaan halaman web. Kami tidak ingin mendorong skenario ketika pengalaman buruk dapat dibenarkan jika Anda dapat memiliki pengalaman yang cukup baik untuk menggantikannya. Pengguna ingin halaman dimuat dengan cepat dan bertransisi ke konten baru dengan cepat, dan kami telah mencoba merancang metrik yang mendukung jenis pengalaman tersebut.
Jadi, meskipun memang benar bahwa versi MPA dari suatu situs mungkin berjalan lebih baik pada metrik Core Web Vitals pada persentil ke-75 daripada versi SPA dari situs yang sama persis, versi SPA harus tetap berusaha untuk memenuhi batas "baik". Jika versi Spa tidak memenuhi batas "baik" bagi sebagian besar pengguna, pengalaman pemuatan awal mungkin masih belum dianggap baik—meskipun pengalaman navigasi dalam halaman selanjutnya sangat baik.
Di masa mendatang, kami berencana mengembangkan metrik yang mendorong pengalaman pasca-pemuatan yang luar biasa, dan kami percaya ini adalah cara terbaik untuk memberikan insentif untuk SpA berkualitas tinggi dengan cara yang tidak mengorbankan pengalaman pemuatan awal. Kami telah mengirimkan metrik baru bernama Interaction to Next Paint (INP) yang mengukur latensi interaksi di seluruh siklus proses halaman, dan kami secara aktif juga mengerjakan metrik pasca-pemuatan lainnya, termasuk metrik yang mengukur transisi rute SPA (lihat di bawah).
Kami beralih situs dari MPA ke SPA dan skor kami menurun. Apakah hal tersebut wajar?
Tergantung. Ada sejumlah alasan mengapa skor Anda dapat berubah setelah migrasi arsitektur besar, tetapi penurunan jumlah pemuatan cache warm dapat menyebabkan beberapa perubahan.
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 metrik Data Web Inti 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 Data Web Inti?
Mungkin tidak. Sebaiknya Anda hanya 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, seiring metrik Data Web Inti meningkat dan mencakup lebih banyak pengalaman penjelajahan, tim dengan SPA yang dibuat dengan baik dan memberikan UX yang bagus harus berharap melihat skor Data Web Inti 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 Data Web Inti (seperti Konsol Penelusuran dan PageSpeed Insights) mendapatkan datanya dari Laporan Pengalaman Pengguna Chrome (CrUX). Dan CrUX menggabungkan data berdasarkan origin atau URL halaman (yaitu, URL halaman pada waktu pemuatan).
Untuk semua alasan yang telah tercantum di atas, CrUX tidak dapat menggabungkan data melalui rute SPA. Namun, sebagai pemilik situs yang memahami arsitektur Anda sendiri, Anda dapat mengukurnya sendiri, dan banyak alat analisis yang memungkinkan Anda menandakan kapan perubahan rute SPA terjadi dan alat tersebut 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 di seluruh siklus proses halaman serta menggabungkannya berdasarkan URL halaman asli agar sesuai dengan cara alat Google mengukur dan melaporkan metrik.
Untuk detail selengkapnya dan praktik terbaik tentang topik ini, lihat: Men-debug performa di kolom.
Apa yang dilakukan Google untuk memastikan MPA tidak memiliki keuntungan yang tidak adil dibandingkan dengan SPA?
Seperti yang disebutkan di atas, MPA yang dioptimalkan dengan tepat dapat, dalam beberapa kasus, melaporkan skor Data Web yang lebih baik pada persentil ke-75 karena fakta bahwa MPA tersebut mungkin akan memiliki persentase kunjungan halaman yang di-cache yang lebih tinggi. Sebaliknya, peningkatan nyata pada pengalaman pengguna di SPA yang dioptimalkan dengan tepat saat ini tidak dicatat oleh metrik Data Web Inti apa 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 memperbaikinya. Saat ini, kami sedang mempelajari dua solusi potensial, satu jangka pendek dan satu jangka panjang:
- Menilai kunjungan lintas origin dan halaman origin yang sama secara terpisah.
- Mendesain API baru yang memungkinkan pengukuran SPA yang lebih baik.
Menilai kunjungan lintas origin dan halaman origin yang sama secara terpisah
Saat ini, metrik Data Web Inti menggabungkan semua kunjungan halaman ke dalam satu bucket—metrik tidak membedakan antara kunjungan baru versus kunjungan kembali atau halaman landing versus halaman checkout atau jenis agregasi lainnya yang mana status cache dapat berpengaruh pada performa.
Salah satu cara untuk menormalisasi perbedaan antara performa SPA dan MPA adalah dengan menerapkan pembobotan yang berbeda untuk jenis kunjungan yang berbeda, bahkan mungkin dengan rekomendasi batas yang benar-benar berbeda.
Meskipun kita tentu ingin menghargai penerapan cache yang efektif, kita tidak ingin navigasi intra-situs yang cepat dapat menutupi pemuatan halaman landing yang lambat. Kami juga tidak ingin memberikan insentif pada situs agar membagi halaman yang panjang menjadi koleksi 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 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 dikerjakan secara aktif (paralel 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 benar (true) jika navigasi dimulai melalui klik link, pengiriman formulir, atau UI kembali atau maju browser. - Metode
transitionWhile(), yang mengambil promise yang memungkinkan developer untuk memberikan sinyal saat pekerjaan yang telah 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. Promise transitionWhile() yang di-resolve dapat membantu browser menghubungkan paint dengan transisi rute tertentu, sehingga browser dapat menentukan contentful paint terbesar yang terkait dengan transisi tersebut.
Berdasarkan ide yang dipresentasikan di bagian sebelumnya, bahkan mungkin Anda dapat menggabungkan waktu transisi rute SPA ke dalam bucket yang sama dengan pemuatan halaman asal yang sama dalam MPA. Hal ini menarik karena akan memungkinkan situs bermigrasi dari MPA ke SPA untuk benar-benar membandingkan performa sebelum dan sesudah.
Tentu saja, diperlukan lebih banyak riset sebelum kami mengetahui apakah kami dapat membuat penentuan ini secara akurat. Jika Anda memiliki saran atau masukan terkait 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 menyadari bahwa ada kesenjangan pengukuran saat ini. Metrik saat ini tidak mencakup setiap aspek pengalaman pengguna, tetapi kami aktif berupaya untuk menutup kekurangan ini.
Terlepas dari keterbatasan saat ini, kami yakin area yang ditangkap metrik yang ada sangat penting untuk kesehatan dan kesuksesan web, dan apabila situs (apa pun arsitekturnya) tidak memenuhi nilai minimum yang direkomendasikan, kami yakin masih ada peningkatan.
Semoga postingan ini dapat membantu menjelaskan tentang subjek yang rumit dan rumit ini. Seperti biasa, jika Anda memiliki masukan tentang metrik Data Web saat ini atau pada masa mendatang, harap kirim email ke web-vitals-feedback@googlegroups.com.