Cara mengukur Data Web dengan alat analisis Anda saat ini.
Kemampuan untuk mengukur dan melaporkan performa halaman Anda di dunia nyata sangat penting untuk mendiagnosis dan meningkatkan performa dari waktu ke waktu. Tanpa data kolom, Anda tidak dapat mengetahui dengan pasti apakah perubahan yang Anda lakukan pada situs benar-benar mencapai hasil yang diinginkan.
Banyak penyedia analisis Pemantauan Pengguna Nyata (RUM) populer sudah mendukung metrik Core Web Vitals di alat mereka (serta banyak Data Web lainnya). Jika saat ini menggunakan salah satu alat analisis RUM ini, Anda berada dalam posisi yang tepat untuk menilai seberapa baik halaman di situs Anda memenuhi nilai minimum Core Web Vitals yang direkomendasikan dan mencegah regresi di masa mendatang.
Meskipun kami merekomendasikan penggunaan alat analisis yang mendukung metrik Core Web Vitals, jika alat analisis yang saat ini Anda gunakan tidak mendukungnya, Anda tidak perlu beralih. Hampir semua alat analisis menawarkan cara untuk menentukan dan mengukur metrik kustom atau peristiwa, yang berarti Anda kemungkinan dapat menggunakan penyedia analisis Anda saat ini untuk mengukur metrik Core Web Vitals dan menambahkannya ke laporan analisis dan dasbor yang ada.
Panduan ini membahas praktik terbaik untuk mengukur metrik Core Web Vitals (atau metrik kustom apa pun) dengan alat analisis pihak ketiga atau internal. Panduan ini juga dapat berfungsi sebagai panduan bagi vendor analisis yang ingin menambahkan dukungan Data Web Inti ke layanan mereka.
Menggunakan metrik atau peristiwa kustom
Seperti yang disebutkan di atas, sebagian besar alat analisis memungkinkan Anda mengukur data kustom. Jika alat analisis Anda mendukung hal ini, Anda akan dapat mengukur setiap metrik Core Web Vitals menggunakan mekanisme ini.
Mengukur metrik atau peristiwa kustom di alat analisis umumnya merupakan proses tiga langkah:
- Tentukan atau daftarkan metrik kustom di admin alat Anda (jika diperlukan). (Catatan: tidak semua penyedia analisis memerlukan metrik kustom untuk ditentukan sebelumnya.)
- Hitung nilai metrik dalam kode JavaScript frontend Anda.
- Kirim nilai metrik ke backend analisis Anda, pastikan nama atau ID cocok dengan yang ditentukan di langkah 1 (lagi, jika diperlukan).
Untuk langkah 1 dan 3, Anda dapat melihat dokumentasi alat analisis untuk mengetahui petunjuknya. Untuk langkah 2, Anda dapat menggunakan library JavaScript web-vitals untuk menghitung nilai setiap metrik Data Web Inti.
Contoh kode berikut menunjukkan betapa mudahnya melacak metrik ini dalam kode dan mengirimkannya ke layanan analisis.
import {onCLS, onINP, onLCP} from 'web-vitals';
function sendToAnalytics({name, value, id}) {
const body = JSON.stringify({name, value, id});
// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
Hindari rata-rata
Anda mungkin ingin menjumlahkan rentang nilai untuk metrik performa dengan menghitung rata-rata. Sekilas tentang rata-rata, terlihat nyaman karena merupakan ringkasan ringkas dari data dalam jumlah besar, tetapi sebaiknya Anda tidak mengandalkannya untuk menafsirkan performa halaman.
Rata-rata bermasalah karena tidak mewakili sesi pengguna tunggal. Pencilan di kedua rentang distribusi dapat mendistorsi rata-rata dengan cara yang menyesatkan.
Misalnya, sekelompok kecil pengguna mungkin menggunakan jaringan atau perangkat yang sangat lambat yang mendekati rentang nilai maksimum, tetapi tidak memperhitungkan sesi pengguna yang cukup untuk memengaruhi rata-rata dengan cara yang menunjukkan adanya masalah.
Jika memungkinkan, andalkan persentil, bukan rata-rata. Persentil di seluruh distribusi untuk metrik performa tertentu lebih menggambarkan berbagai pengalaman pengguna untuk situs Anda. Hal ini memungkinkan Anda berfokus pada subset pengalaman sebenarnya, yang akan memberi Anda lebih banyak insight daripada nilai tunggal.
Memastikan Anda dapat melaporkan distribusi
Setelah menghitung nilai untuk setiap metrik Data Web Inti dan mengirimnya ke layanan analisis menggunakan metrik atau peristiwa kustom, langkah berikutnya adalah membuat laporan atau dasbor yang menampilkan nilai yang telah dikumpulkan.
Untuk memastikan Anda memenuhi batas Data Web Inti yang direkomendasikan, Anda harus membuat laporan menampilkan nilai setiap metrik pada persentil ke-75.
Jika alat analisis Anda tidak menawarkan pelaporan kuantil sebagai fitur bawaan, Anda mungkin masih bisa mendapatkan data ini secara manual dengan membuat laporan yang mencantumkan setiap nilai metrik yang diurutkan dalam urutan menaik. Setelah laporan ini dibuat, hasil yang merupakan 75% dari daftar lengkap dan diurutkan dari semua nilai dalam laporan tersebut akan menjadi persentil ke-75 untuk metrik tersebut—dan hal ini akan terjadi terlepas dari cara Anda menyegmentasikan data (menurut jenis perangkat, jenis koneksi, negara, dll.).
Jika alat analisis tidak memberikan perincian pelaporan tingkat metrik secara default, Anda mungkin dapat mencapai hasil yang sama jika alat analisis mendukung dimensi kustom. Dengan menetapkan nilai dimensi kustom yang unik untuk setiap instance metrik yang Anda lacak, Anda akan dapat membuat laporan, yang dikelompokkan menurut setiap instance metrik, jika menyertakan dimensi kustom dalam konfigurasi laporan. Karena setiap instance akan memiliki nilai dimensi yang unik, tidak akan ada pengelompokan.
Laporan Data Web adalah contoh teknik ini yang menggunakan Google Analytics. Kode untuk laporan adalah open source, sehingga developer dapat mereferensikannya sebagai contoh teknik yang diuraikan di bagian ini.
Mengirim data Anda pada waktu yang tepat
Beberapa metrik performa dapat dihitung setelah halaman selesai dimuat, sementara metrik lainnya (seperti CLS) mempertimbangkan seluruh masa aktif halaman—dan hanya bersifat final setelah halaman mulai di-unload.
Namun, hal ini dapat menjadi masalah karena peristiwa beforeunload dan unload tidak dapat diandalkan (terutama di perangkat seluler) dan penggunaannya tidak direkomendasikan (karena dapat membuat halaman tidak memenuhi syarat untuk Back-Forward Cache).
Untuk metrik yang melacak seluruh masa aktif halaman, sebaiknya kirim nilai metrik saat ini selama peristiwa visibilitychange, setiap kali status visibilitas halaman berubah menjadi hidden. Hal ini karena—setelah status visibilitas halaman berubah menjadi hidden—tidak ada jaminan bahwa skrip apa pun di halaman tersebut akan dapat berjalan lagi. Hal ini terutama berlaku pada sistem operasi
seluler tempat aplikasi browser dapat ditutup tanpa mengaktifkan callback
halaman.
Perhatikan bahwa sistem operasi seluler umumnya mengaktifkan peristiwa visibilitychange
saat beralih tab, beralih aplikasi, atau menutup aplikasi browser itu sendiri.
Peristiwa ini juga memicu peristiwa visibilitychange saat menutup tab atau membuka halaman baru. Hal ini membuat peristiwa visibilitychange jauh lebih andal daripada peristiwa unload atau beforeunload.
Memantau performa dari waktu ke waktu
Setelah memperbarui penerapan analisis untuk melacak dan melaporkan metrik Data Web Inti, langkah berikutnya adalah melacak pengaruh perubahan pada situs terhadap performa dari waktu ke waktu.
Membuat versi perubahan
Pendekatan sederhana (dan pada akhirnya tidak dapat diandalkan) untuk melacak perubahan adalah dengan men-deploy perubahan ke produksi, lalu mengasumsikan bahwa semua metrik yang diterima setelah tanggal deployment sesuai dengan situs baru dan semua metrik yang diterima sebelum tanggal deployment sesuai dengan situs lama. Namun, sejumlah faktor (termasuk penyimpanan dalam cache di lapisan HTTP, pekerja layanan, atau CDN) dapat mencegah hal ini berfungsi.
Pendekatan yang jauh lebih baik adalah membuat versi unik untuk setiap perubahan yang di-deploy, lalu melacak versi tersebut di alat analisis Anda. Sebagian besar alat analisis mendukung penentuan versi. Jika tidak, Anda dapat membuat dimensi kustom dan menetapkan dimensi tersebut ke versi yang di-deploy.
Jalankan percobaan
Anda dapat melakukan pembuatan versi lebih lanjut dengan melacak beberapa versi (atau eksperimen) secara bersamaan.
Jika alat analisis memungkinkan Anda menentukan grup eksperimen, gunakan fitur tersebut. Atau, Anda dapat menggunakan dimensi kustom untuk memastikan setiap nilai metrik dapat dikaitkan dengan grup eksperimen tertentu dalam laporan Anda.
Dengan menerapkan eksperimen di analisis, Anda dapat meluncurkan perubahan eksperimental pada sebagian pengguna dan membandingkan performa perubahan tersebut dengan performa pengguna di grup kontrol. Setelah merasa yakin bahwa perubahan tersebut memang meningkatkan performa, Anda dapat meluncurkannya kepada semua pengguna.
Memastikan pengukuran tidak memengaruhi performa
Saat mengukur performa pada pengguna sungguhan, kode pengukuran performa apa pun yang Anda jalankan tidak boleh berdampak negatif pada performa halaman Anda. Jika demikian, setiap kesimpulan yang Anda coba buat tentang pengaruh performa terhadap bisnis Anda tidak akan dapat diandalkan, karena Anda tidak akan pernah tahu apakah kehadiran kode analisis itu sendiri memiliki dampak negatif terbesar.
Selalu ikuti prinsip-prinsip ini saat men-deploy kode analisis RUM di situs produksi Anda:
Menunda analisis
Kode Analytics harus selalu dimuat dengan cara asinkron dan tidak memblokir, dan umumnya harus dimuat terakhir. Jika Anda memuat kode analisis dengan cara yang memblokir, hal ini dapat berdampak negatif pada LCP.
Semua API yang digunakan untuk mengukur metrik Data Web Inti dirancang secara khusus
untuk mendukung pemuatan skrip asinkron dan tertunda (melalui
tanda buffered), sehingga
Anda tidak perlu terburu-buru untuk memuat skrip lebih awal.
Jika Anda mengukur metrik yang tidak dapat dihitung nanti dalam
linimasa pemuatan halaman, Anda harus menyisipkan hanya kode yang perlu dijalankan lebih awal
ke dalam <head> dokumen Anda (sehingga bukan permintaan pemblokiran
render) dan menunda sisanya. Jangan memuat semua analitik Anda lebih awal hanya karena satu metrik memerlukannya.
Jangan membuat tugas yang berjalan lama
Kode Analytics sering berjalan sebagai respons terhadap input pengguna, tetapi jika kode Analytics Anda melakukan banyak pengukuran DOM atau menggunakan API lain yang intensif prosesor, kode Analytics itu sendiri dapat menyebabkan responsivitas input yang buruk. Selain itu, jika file JavaScript yang berisi kode analisis Anda berukuran besar, menjalankan file tersebut dapat memblokir thread utama dan memengaruhi Interaksi ke Gambar Berikutnya (INP) halaman secara negatif.
Menggunakan API non-blocking
API seperti
sendBeacon()
dan
requestIdleCallback()
dirancang khusus untuk menjalankan tugas non-kritis dengan cara yang tidak
memblokir tugas penting pengguna.
API ini merupakan alat yang sangat bagus untuk digunakan dalam library analisis RUM.
Secara umum, semua beacon analisis harus dikirim menggunakan sendBeacon() API
(jika tersedia), dan semua kode pengukuran analisis pasif harus dijalankan selama
periode tidak ada aktivitas.
Jangan melacak lebih dari yang Anda perlukan
Browser mengekspos banyak data performa, tetapi hanya karena data tersebut tersedia, bukan berarti Anda harus mencatatnya dan mengirimkannya ke server analisis.
Misalnya, Resource Timing API menyediakan data pengaturan waktu mendetail untuk setiap resource yang dimuat di halaman Anda. Namun, kemungkinan besar semua data tersebut tidak diperlukan atau berguna dalam meningkatkan performa pemuatan resource.
Singkatnya, jangan hanya melacak data karena data tersebut ada, pastikan data akan digunakan sebelum menggunakan resource untuk melacaknya.