Praktik terbaik untuk mengukur Data Web di lapangan

Cara mengukur Data Web dengan alat analisis Anda yang sudah ada.

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 mungkin dapat menggunakan penyedia analisis saat ini untuk mengukur metrik Core Web Vitals dan menambahkannya ke laporan dan dasbor analisis 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 mendukungnya, Anda akan dapat mengukur setiap metrik Data Web Inti menggunakan mekanisme ini.

Mengukur metrik atau peristiwa kustom di alat analisis umumnya merupakan proses tiga langkah:

  1. Tentukan atau daftarkan metrik kustom di admin alat Anda (jika diperlukan). (Catatan: tidak semua penyedia analisis mengharuskan metrik kustom ditentukan terlebih dahulu.)
  2. Hitung nilai metrik dalam kode JavaScript frontend Anda.
  3. 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);

Menghindari rata-rata

Anda mungkin ingin menjumlahkan rentang nilai untuk metrik performa dengan menghitung rata-rata. Rata-rata tampak praktis pada pandangan pertama, karena merupakan ringkasan rapi dari data dalam jumlah besar, tetapi Anda harus menahan keinginan untuk mengandalkan rata-rata tersebut untuk menafsirkan performa halaman.

Rata-rata bermasalah karena tidak mewakili sesi pengguna tunggal. Pencilan di salah satu 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, gunakan 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 kuartil 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 bersifat open source, sehingga developer dapat mereferensikannya sebagai contoh teknik yang diuraikan di bagian ini.

Screenshot Laporan Data Web

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 mencegah halaman memenuhi syarat untuk Cache Kembali-Maju).

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 itu sendiri dapat ditutup tanpa callback halaman yang diaktifkan.

Perhatikan bahwa sistem operasi seluler umumnya memicu 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 eksperimen yang diterapkan di analisis, Anda dapat meluncurkan perubahan eksperimental kepada sebagian pengguna dan membandingkan performa perubahan tersebut dengan performa pengguna dalam 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 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 secara khusus untuk menjalankan tugas non-penting dengan cara yang tidak memblokir tugas penting pengguna.

API ini adalah alat yang bagus untuk digunakan di 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 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.