Pengukuran Web Vitals dari pengunjung sendiri baru berguna bila satu pengalaman tidak dihitung berkali-kali. Callback yang muncul lagi saat tab disembunyikan bukan otomatis pengunjung baru. Sebelum membuat dashboard, tetapkan identitas metrik, cara memperbarui nilainya, dan kunjungan mana yang tercakup.
Real User Monitoring atau RUM adalah pengumpulan pengalaman pengguna pada website yang benar-benar mereka buka. Panduan ini ditujukan untuk developer dan analis yang ingin menyiapkan pengukuran tersebut. Hasil akhirnya berupa kontrak data yang bisa diuji, bukan klaim bahwa memasang satu script langsung menghasilkan data sempurna.
Untuk menentukan pertanyaan yang tepat bagi pengukuran ini, pahami dahulu perbedaan data lapangan dan data lab.
Mulai dari pertanyaan yang akan dijawab
Misalnya, kamu ingin mengetahui apakah template artikel dengan galeri mempunyai masalah kestabilan tampilan pada perangkat mobile. Kamu membutuhkan nama template dan kelompok perangkat yang konsisten. Kamu belum tentu membutuhkan URL lengkap, apalagi parameter yang berisi email atau pencarian pengguna.
Tuliskan cakupan awal: template artikel, navigasi dokumen penuh, browser yang mendukung, dan aturan persetujuan pengukuran yang berlaku pada situs. Jika aplikasi memakai navigasi tanpa reload, putuskan secara terpisah bagaimana navigasi tersebut diukur. Jangan mencampurkan cakupan baru ke seri lama tanpa penanda.
Mulai dari satu template membuat pengujian lebih mudah. Setelah jalur datanya benar, perluas ke template lain dengan kontrak yang sama.
Pahami kapan callback muncul
Pustaka resmi web-vitals menyediakan onLCP, onINP, dan onCLS. Sebagian nilai dilaporkan ketika pengguna berinteraksi atau halaman menjadi tersembunyi. INP dapat tidak tersedia ketika tidak ada interaksi. Callback juga dapat muncul lebih dari sekali, dan pemulihan dari back/forward cache mempunyai identitas metrik baru. Dokumentasi web-vitals.
Karena itu, jangan menulis tes yang mengharuskan tiga nilai langsung muncul sesaat setelah halaman dibuka. Jangan pula mengisi INP yang tidak tersedia dengan nol. Nol menyatakan nilai terukur; tidak tersedia menyatakan keterbatasan pengamatan.
Daftarkan fungsi pengukuran sekali pada lifecycle yang dimaksud. Pada aplikasi berbasis komponen, periksa apakah perpindahan route atau pemasangan ulang komponen tanpa sengaja membuat observer tambahan.
Tetapkan bentuk data sebelum memilih dashboard
Berikut rancangan ilustratif untuk disepakati developer dan analis:
| Field | Contoh | Fungsi |
|---|---|---|
metric_name |
CLS |
Memisahkan metrik dan satuannya |
metric_id |
metric-a |
Menggabungkan pembaruan metrik yang sama |
value |
0.09 |
Nilai metrik pada laporan ini |
delta |
0.05 |
Perubahan sejak laporan sebelumnya |
sequence |
2 |
Urutan laporan dari pengirim |
template |
article-gallery |
Kelompok halaman yang sedang diperiksa |
release |
release-b |
Versi aplikasi untuk konteks perubahan |
navigation_scope |
document |
Menjelaskan jenis navigasi yang diukur |
sequence adalah usulan field implementasi, bukan properti bawaan yang otomatis diberikan semua pustaka. Identitas metrik juga bukan identitas orang. Tentukan cakupan keunikannya dan jangan menggunakannya untuk menyatakan jumlah pembaca unik.
Untuk URL, pilih identitas halaman yang sudah dibersihkan atau nama template. Tetapkan masa penyimpanan dan akses sesuai kebutuhan pengukuran. Mengirim seluruh objek diagnostic tanpa meninjau isinya dapat membawa konteks yang tidak diperlukan.
Contoh: dua laporan CLS dari pengalaman yang sama
Angka berikut hanya contoh ilustratif:
| Metric ID | Urutan | Value | Delta |
|---|---|---|---|
metric-a |
1 | 0.04 | 0.04 |
metric-a |
2 | 0.09 | 0.05 |
metric-b |
1 | 0.02 | 0.02 |
Untuk metric-a, hasil akhirnya adalah 0.09. Menjumlahkan kolom value menjadi 0.13 adalah keliru. Pilih satu kebijakan: menyimpan value dari urutan terakhir, atau menjumlahkan delta dari laporan unik dengan ID yang sama. Pustaka mendukung kedua pola pelaporan tersebut, tetapi sistem penyimpananmu harus menerapkannya dengan konsisten.
Jika request kedua dicoba ulang karena jaringan putus, event yang sama bisa diterima lagi. Berikan mekanisme deduplikasi laporan, misalnya kombinasi ID dan urutan. Untuk pola value terakhir, jangan biarkan request lama yang terlambat datang menimpa nilai lebih baru.
Baru setelah satu nilai akhir per pengalaman tersusun, hitung distribusi dan persentil yang kamu butuhkan. Rata-rata semua callback akan memberi bobot lebih besar kepada pengalaman yang mengirim banyak pembaruan.
Uji dari browser sampai data tersimpan
Gunakan lingkungan uji dan tujuan pengukuran yang sesuai. Simpan hasil yang diharapkan sebelum menjalankan skenario:
| Skenario | Hal yang diperiksa |
|---|---|
| Buka halaman tanpa berinteraksi | INP yang hilang tetap ditandai tidak tersedia |
| Klik kontrol lalu pindah tab | Callback dan satuan sampai ke tujuan yang benar |
| Tab disembunyikan beberapa kali | Pembaruan tidak menjadi pengalaman baru |
| Navigasi kembali dari riwayat | Lifecycle dan identitas baru ditangani sesuai pustaka |
| Pengiriman diulang | Laporan yang sama tidak dihitung dua kali |
| Pengukuran tidak diizinkan | Jalur pengiriman mengikuti keputusan consent situs |
Cocokkan callback, request, record yang diterima, lalu hasil agregasi. Screenshot console hanya membuktikan callback lokal. Request yang terlihat juga belum membuktikan dashboard memakai aturan deduplikasi yang benar.
Tampilkan cakupan bersama hasil
Simpan jumlah sampel, periode, template, perangkat, browser, dan versi implementasi. Browser yang tidak tercakup atau pengguna yang tidak mengizinkan pengukuran membuat RUM berbeda dari seluruh populasi. Perbedaan hasil dengan CrUX perlu dibaca bersama perbedaan cakupan tersebut. Panduan pengukuran Web Vitals.
Jika sampel masih kecil, gunakan hasil untuk mencari pola yang perlu diuji, lalu lanjutkan diagnosis lab. Jangan mengumumkan template sehat hanya karena belum ada nilai buruk.
Pekerjaan pertama yang dapat kamu lakukan adalah membuat tiga baris contoh seperti tabel CLS tadi, memasukkannya ke transformasi data, lalu memeriksa bahwa hasil akhirnya tetap dua pengalaman dengan nilai 0.09 dan 0.02. Perhitungan kecil ini melindungi dashboard besar dari kesalahan mendasar.
