Cara mengukur Data Web dengan alat analisis Anda saat ini.
Kemampuan untuk mengukur dan melaporkan performa dunia nyata halaman Anda sangat penting untuk mendiagnosis dan meningkatkan performa dari waktu ke waktu. Tanpa data kolom, mustahil untuk mengetahui secara pasti apakah perubahan yang Anda lakukan pada situs benar-benar mencapai hasil yang diinginkan.
Banyak penyedia analisis Real User Monitoring (RUM) populer yang sudah mendukung metrik Data Web Inti di alat mereka (serta banyak Data Web lainnya). Jika saat ini Anda menggunakan salah satu alat analisis RUM ini, Anda dapat menilai seberapa baik halaman di situs Anda memenuhi nilai minimum Data Web Inti yang direkomendasikan dan mencegah regresi di masa mendatang.
Meskipun kami merekomendasikan penggunaan alat analisis yang mendukung metrik Data Web Inti, jika alat analisis yang Anda gunakan saat ini tidak mendukungnya, Anda tidak perlu beralih. Hampir semua alat analisis menawarkan cara untuk menentukan dan mengukur metrik kustom atau peristiwa, yang berarti Anda mungkin dapat menggunakan penyedia analisis saat ini untuk mengukur metrik Data Web Inti dan menambahkannya ke laporan analisis dan dasbor yang ada.
Panduan ini membahas praktik terbaik untuk mengukur metrik Data Web Inti (atau metrik kustom apa pun) dengan alat analisis pihak ketiga atau internal. Laporan ini juga dapat berfungsi sebagai panduan bagi vendor analisis yang ingin menambahkan dukungan Core Web Vitals ke layanan mereka.
Menggunakan peristiwa atau metrik kustom
Seperti yang disebutkan di atas, sebagian besar alat analisis memungkinkan Anda mengukur data kustom. Jika alat analisis Anda mendukungnya, Anda seharusnya dapat mengukur setiap metrik Core Web Vitals menggunakan mekanisme ini.
Mengukur metrik kustom atau peristiwa di alat analisis umumnya merupakan proses tiga langkah:
- Tentukan atau daftarkan metrik kustom di admin fitur Anda (jika perlu). (Catatan: tidak semua penyedia analisis mengharuskan metrik kustom ditentukan terlebih dahulu.)
- Hitung nilai metrik di kode JavaScript frontend Anda.
- Kirim nilai metrik ke backend analisis Anda, dengan memastikan nama atau ID cocok dengan yang ditentukan di langkah 1 (sekali 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, onFID, 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);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);
Hindari rata-rata
Anda mungkin ingin menjumlahkan rentang nilai untuk metrik performa dengan menghitung rata-rata. Secara sekilas, rata-rata tampak praktis, karena merupakan ringkasan rapi dari data dalam jumlah besar, tetapi Anda tidak perlu mengandalkannya untuk menafsirkan performa halaman.
Rata-rata bermasalah karena tidak merepresentasikan sesi pengguna tunggal mana pun. 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 cukup banyak sesi pengguna 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 menjelaskan keseluruhan pengalaman pengguna untuk situs Anda. Hal ini memungkinkan Anda untuk berfokus pada subkumpulan pengalaman sebenarnya, yang akan memberi Anda lebih banyak insight daripada nilai tunggal yang pernah ada.
Pastikan Anda dapat melaporkan distribusi
Setelah Anda menghitung nilai untuk setiap metrik Data Web Inti dan mengirimkannya ke layanan analisis menggunakan metrik atau peristiwa kustom, langkah selanjutnya adalah membuat laporan atau dasbor yang menampilkan nilai yang telah dikumpulkan.
Untuk memastikan Anda memenuhi nilai minimum Data Web Inti yang direkomendasikan, laporan harus menampilkan nilai setiap metrik pada persentil ke-75.
Jika alat analisis 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 mencakup 75% dari daftar lengkap yang diurutkan dari semua nilai dalam laporan tersebut akan menjadi persentil ke-75 untuk metrik tersebut—dan ini akan terjadi terlepas dari bagaimana Anda mengelompokkan data (menurut jenis perangkat, jenis koneksi, negara, dll.).
Jika alat analisis Anda tidak memberi Anda perincian pelaporan tingkat metrik secara default, Anda mungkin dapat mencapai hasil yang sama jika alat analisis Anda mendukung dimensi kustom. Dengan menetapkan nilai dimensi kustom yang unik untuk setiap instance metrik yang dilacak, Anda akan dapat membuat laporan, yang dikelompokkan menurut instance metrik individual, jika Anda menyertakan dimensi kustom dalam konfigurasi laporan. Karena setiap instance akan memiliki nilai dimensi yang unik, maka tidak akan ada pengelompokan.
Laporan Data Web adalah contoh teknik yang menggunakan Google Analytics ini. Kode untuk laporan ini adalah open source, sehingga developer dapat mereferensikannya sebagai contoh teknik yang diuraikan di bagian ini.
Mengirim data pada waktu yang tepat
Beberapa metrik performa dapat dihitung setelah halaman selesai dimuat, sementara yang lain (seperti CLS) mempertimbangkan keseluruhan masa aktif halaman—dan hanya final setelah halaman mulai menghapus muatannya.
Namun, hal ini dapat menjadi masalah, karena peristiwa beforeunload dan unload
tidak dapat diandalkan (terutama di perangkat seluler) dan penggunaannya tidak
direkomendasikan
(karena dapat mencegah halaman memenuhi syarat untuk Cache
Back-Forward).
Untuk metrik yang melacak keseluruhan masa aktif halaman, sebaiknya kirim apa pun
nilai metrik saat ini selama peristiwa visibilitychange, setiap kali
status visibilitas halaman berubah menjadi hidden. 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 itu sendiri dapat ditutup tanpa mengaktifkan callback halaman.
Perlu diperhatikan bahwa sistem operasi seluler umumnya mengaktifkan peristiwa visibilitychange saat beralih tab, beralih aplikasi, atau menutup aplikasi browser.
Tindakan ini juga mengaktifkan 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 implementasi analisis untuk melacak dan melaporkan metrik Data Web Inti, langkah berikutnya adalah melacak bagaimana perubahan pada situs Anda memengaruhi performa dari waktu ke waktu.
Membuat versi perubahan
Pendekatan yang naif (dan pada akhirnya tidak dapat diandalkan) untuk melacak perubahan adalah menerapkan perubahan pada 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 caching di lapisan HTTP, pekerja layanan, atau CDN) dapat mencegahnya 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 penetapan versi. Jika tidak, Anda dapat membuat dimensi kustom dan menetapkan dimensi tersebut ke versi yang di-deploy.
Jalankan percobaan
Anda dapat membuat versi satu langkah lebih jauh dengan melacak beberapa versi (atau eksperimen) secara bersamaan.
Jika alat analisis memungkinkan Anda menentukan grup eksperimen, gunakan fitur tersebut. Jika tidak, Anda dapat menggunakan dimensi kustom untuk memastikan setiap nilai metrik dapat dikaitkan dengan grup eksperimen tertentu dalam laporan Anda.
Dengan eksperimen yang diterapkan di analisis, Anda dapat meluncurkan perubahan eksperimental ke subkumpulan pengguna dan membandingkan performa perubahan tersebut dengan performa pengguna di grup kontrol. Setelah yakin bahwa perubahan akan benar-benar meningkatkan performa, Anda dapat meluncurkannya ke semua pengguna.
Memastikan pengukuran tidak memengaruhi performa
Saat mengukur performa pada pengguna sungguhan, kode pengukuran performa apa pun yang Anda jalankan tidak akan berdampak negatif terhadap performa halaman. Jika ya, setiap kesimpulan yang Anda coba ambil tentang pengaruh performa Anda terhadap bisnis tidak akan dapat diandalkan, karena Anda tidak akan pernah tahu apakah keberadaan kode analisis itu sendiri memiliki dampak negatif terbesar.
Selalu ikuti prinsip-prinsip ini saat men-deploy kode analisis RUM di situs produksi Anda:
Tunda analisis Anda
Kode Analytics harus selalu dimuat dengan cara yang asinkron dan tidak memblokir, dan umumnya harus dimuat terakhir. Jika Anda memuat kode analisis dengan cara yang menghalangi, hal tersebut dapat berdampak negatif pada LCP.
Semua API yang digunakan untuk mengukur metrik Data Web Inti didesain secara khusus
untuk mendukung pemuatan skrip yang asinkron dan ditangguhkan (melalui
tanda buffered), sehingga
Anda tidak perlu terburu-buru memuat skrip Anda lebih awal.
Jika Anda mengukur metrik yang tidak dapat dihitung nanti dalam
linimasa pemuatan halaman, Anda harus hanya menjalankan kode yang perlu dijalankan di awal
ke <head> dokumen Anda (jadi ini bukan permintaan yang memblokir
rendering) dan menunda sisanya. Jangan muat semua analisis Anda lebih awal hanya karena satu metrik memerlukannya.
Jangan buat tugas yang panjang
Kode Analytics sering dijalankan sebagai respons terhadap input pengguna, tetapi jika kode analisis Anda melakukan banyak pengukuran DOM atau menggunakan API yang sarat prosesor lainnya, kode analisis itu sendiri dapat menyebabkan responsivitas input yang buruk. Selain itu, jika file JavaScript yang berisi kode analisis Anda berukuran besar, mengeksekusi file tersebut dapat memblokir thread utama dan berdampak negatif pada First Input Delay (FID) atau Interaction to Next Paint (INP).
Menggunakan API yang tidak memblokir
API seperti
sendBeacon()
dan
requestIdleCallback()
dirancang khusus untuk menjalankan tugas non-kritis dengan cara yang tidak
memblokir tugas yang penting bagi pengguna.
API ini merupakan alat yang hebat 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 butuhkan
Browser mengekspos banyak data performa. Namun, hanya karena data tersebut sudah tersedia, bukan berarti Anda harus mencatat dan mengirimkannya ke server analisis.
Misalnya, Resource Timing API menyediakan data pengaturan waktu yang mendetail untuk setiap resource yang dimuat di halaman Anda. Namun, kemungkinan tidak semua data tersebut akan selalu atau berguna dalam meningkatkan performa pemuatan resource.
Singkatnya, jangan hanya melacak data karena data tersedia, pastikan data akan digunakan sebelum memakai resource yang melacaknya.