Cara mengukur Data Web dengan alat analisis Anda saat ini.
Memiliki kemampuan untuk mengukur dan melaporkan performa di dunia nyata halaman sangat penting untuk mendiagnosis dan meningkatkan performa dari waktu ke waktu. Tanpa kolom data, kita tidak mungkin mengetahui secara pasti apakah perubahan yang Anda lakukan pada situs benar-benar mencapai hasil yang diinginkan.
Banyak Pemantauan Pengguna Nyata (RUM) penyedia analisis sudah mendukung metrik Core Web Vitals dalam (serta banyak Data Web lainnya). Jika Anda menggunakan salah satu alat analisis RUM ini, Anda sudah siap untuk nilai seberapa baik halaman di situs Anda memenuhi Data Web Inti yang direkomendasikan minimum dan mencegah regresi di masa mendatang.
Meskipun kami merekomendasikan penggunaan alat analisis yang mendukung Core Web Vitals jika alat analisis yang digunakan saat ini tidak mendukungnya, Anda tidak perlu beralih. Hampir semua alat analitik menawarkan cara untuk tentukan dan ukur metrik kustom metrik atau peristiwa, yang berarti Anda mungkin dapat menggunakan penyedia analisis Anda saat ini untuk mengukur 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. Data ini juga dapat berfungsi sebagai panduan bagi vendor analisis yang ingin menambahkan dukungan Core Web Vitals 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 mendukung ini, Anda harus dapat mengukur setiap data Metrik Android vitals menggunakan mekanisme ini.
Mengukur metrik atau peristiwa kustom dalam alat analisis umumnya merupakan proses tiga langkah:
- Mendefinisikan atau mendaftar metrik kustom di admin alat Anda (jika perlu). (Catatan: tidak semua penyedia analisis mengharuskan metrik kustom ditentukan sebelumnya.)
- Hitung nilai metrik di kode JavaScript frontend Anda.
- Kirim nilai metrik ke backend analisis Anda, dengan memastikan nama atau ID cocok dengan yang ditentukan pada langkah 1 (sekali lagi, jika diperlukan).
Untuk langkah 1 dan 3, Anda dapat melihat dokumentasi alat analisis untuk petunjuk. Untuk langkah 2, Anda dapat menggunakan library JavaScript web-vitals untuk menghitung nilai setiap metrik Core Web Vitals.
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 tampak nyaman, karena ringkasan yang rapi dari sejumlah besar data, tetapi Anda harus menahan keinginan untuk mengandalkan untuk menafsirkan performa halaman.
Rata-rata bermasalah karena tidak merepresentasikan sesi pengguna tunggal mana pun. Pencilan di kedua rentang dari distribusi dapat mencondongkan rata-rata dengan cara yang menyesatkan.
Misalnya, sekelompok kecil pengguna mungkin menggunakan jaringan atau perangkat yang sangat lambat mendekati rentang nilai maksimum, tetapi tidak memperhitungkan jumlah pengguna sesi untuk mempengaruhi rata-rata dengan cara yang menunjukkan adanya masalah.
Jika memungkinkan, andalkan persentil, bukan rata-rata. Persentil di seluruh untuk metrik performa tertentu dengan lebih baik menggambarkan berbagai macam pengalaman pengguna untuk {i>website<i} Anda. Hal ini memungkinkan Anda untuk fokus pada {i>subset <i}dari aktual, yang akan memberi Anda lebih banyak insight daripada nilai tunggal bisa.
Memastikan Anda dapat melaporkan distribusi
Setelah Anda menghitung nilai untuk setiap metrik Core Web Vitals dan mengirim pengguna ke layanan analisis Anda menggunakan metrik atau peristiwa kustom, langkah selanjutnya adalah untuk membuat laporan atau dasbor yang menampilkan nilai yang telah dikumpulkan.
Untuk memastikan Anda memenuhi Core Web Vitals yang direkomendasikan minimum, Anda memerlukan laporan untuk 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, yakni 75% dari seluruh daftar lengkap yang diurutkan dari semua nilai dalam laporan itu akan menjadi persentil ke-75 untuk metrik itu—dan ini akan menjadi tidak peduli bagaimana cara Anda menyegmentasi data (menurut jenis perangkat, jenis koneksi, negara, dll.).
Jika alat analisis tidak memberikan perincian pelaporan tingkat metrik sebesar default, Anda mungkin dapat mencapai hasil yang sama jika alat analisis mendukung kustom dimensi. Dengan menetapkan nilai dimensi kustom yang unik untuk setiap instance metrik yang Anda lacak, Anda seharusnya bisa membuat laporan, yang dikelompokkan menurut metrik individual default, jika Anda menyertakan dimensi kustom dalam konfigurasi laporan. Karena setiap instance akan memiliki nilai dimensi yang unik, pengelompokan tidak akan terjadi.
Laporan Data Web adalah contoh teknik ini yang menggunakan Google Analytics. Kode untuk laporannya bersifat open source, sehingga developer dapat mereferensikannya sebagai contoh teknik yang diuraikan dalam bagian.
Mengirim data pada waktu yang tepat
Beberapa metrik performa dapat dihitung setelah halaman selesai dimuat, sementara yang lain (seperti CLS) mempertimbangkan seluruh masa aktif halaman—dan hanya setelah halaman mulai menghapus muatan.
Namun, hal ini bisa menjadi masalah karena beforeunload dan unload
peristiwa tidak dapat diandalkan (terutama di perangkat seluler) dan penggunaannya tidak
direkomendasikan
(karena mereka dapat mencegah laman memenuhi syarat untuk aktivitas Back-Forward
Cache).
Untuk metrik yang melacak keseluruhan masa aktif halaman, sebaiknya kirim data yang
nilai metrik saat ini adalah selama peristiwa visibilitychange, kapan pun
status visibilitas halaman berubah menjadi hidden. Hal ini karena—setelah halaman
status visibilitas berubah menjadi hidden—tidak ada jaminan bahwa skrip di
halaman tersebut dapat berjalan lagi. Hal ini terutama berlaku pada
operasi seluler
sistem yang memungkinkan aplikasi browser ditutup tanpa callback halaman
dipecat.
Perhatikan bahwa sistem operasi seluler umumnya mengaktifkan visibilitychange
saat beralih tab, beralih aplikasi, atau menutup aplikasi browser.
Pengguna juga mengaktifkan peristiwa visibilitychange saat menutup tab atau membuka
laman baru. Hal ini membuat peristiwa visibilitychange jauh lebih andal daripada
Peristiwa unload atau beforeunload.
Pantau performa dari waktu ke waktu
Setelah Anda memperbarui penerapan analisis ke jalur dan pelaporan metrik Core Web Vitals, langkah berikutnya adalah melacak perubahan pada situs memengaruhi performa dari waktu ke waktu.
Membuat versi perubahan Anda
Pendekatan naif (dan pada akhirnya tidak dapat diandalkan) dalam melacak perubahan adalah perubahan pada produksi, lalu asumsikan bahwa semua metrik diterima setelah tanggal deployment sesuai dengan situs baru dan semua metrik yang diterima sebelum tanggal penerapan sesuai dengan situs lama. Namun, sejumlah faktor (termasuk caching di lapisan HTTP, pekerja layanan, atau CDN) dapat mencegah hal ini dari bekerja.
Pendekatan yang jauh lebih baik adalah membuat versi unik untuk setiap perubahan yang di-deploy dan melacak versi tersebut di alat analisis. Sebagian besar alat analisis mendukung menetapkan versi. Jika tidak, Anda dapat membuat dimensi kustom dan dimensi tersebut ke versi yang di-deploy.
Jalankan percobaan
Anda dapat membuat versi selangkah lebih maju 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 di laporan Anda.
Dengan menerapkan eksperimen di analisis, Anda dapat meluncurkan perubahan eksperimental ke sekelompok pengguna Anda dan bandingkan performa yang mengubah kinerja pengguna di grup kontrol. Setelah Anda memiliki keyakinan bahwa perubahan benar-benar meningkatkan kinerja, Anda dapat meluncurkannya ke semua pengguna.
Memastikan pengukuran tidak memengaruhi performa
Saat mengukur kinerja pada pengguna yang sesungguhnya, sangat penting bahwa kode pengukuran performa yang Anda jalankan tidak berdampak negatif performa halaman Anda. Jika ya, maka kesimpulan apa pun yang Anda coba tarik pengaruh kinerja terhadap bisnis Anda tidak akan dapat diandalkan, karena tidak pernah tahu apakah keberadaan kode analitik itu sendiri merupakan dampak negatif.
Selalu ikuti prinsip-prinsip ini saat men-deploy kode analisis RUM pada situs produksi:
Menunda analisis
Kode Analytics harus selalu dimuat dengan cara asinkron, tidak memblokir, dan umumnya itu harus dimuat terakhir. Jika Anda memuat kode analisis di sehingga akan menghambat LCP, hal itu dapat berdampak negatif pada LCP.
Semua API yang digunakan untuk mengukur metrik Core Web Vitals secara spesifik
yang dirancang untuk mendukung pemuatan skrip asinkron dan ditangguhkan (melalui
buffered), jadi
Anda tidak perlu terburu-buru memuat
skrip Anda lebih awal.
Jika Anda mengukur metrik yang tidak dapat dihitung nanti dalam
Anda harus hanya menyisipkan kode yang perlu dijalankan lebih awal
ke dalam <head> dokumen Anda (jadi tidak merupakan pemblokiran render
permintaan) dan menunda sisanya. Jangan muat semua
analitik data lebih awal hanya karena
satu metrik memerlukannya.
Jangan membuat tugas yang berjalan lama
Kode analisis sering dijalankan sebagai respons terhadap input pengguna, tetapi jika kode analisis Anda melakukan banyak pengukuran DOM atau menggunakan API intensif prosesor lainnya kode analitik itu sendiri dapat menyebabkan respons input yang buruk. Selain itu, jika file JavaScript yang berisi kode analisis Anda berukuran besar, sehingga mengeksekusi file tersebut dapat memblokir thread utama dan berdampak negatif pada Interaction to Next Paint (INP) halaman.
Menggunakan API yang tidak memblokir
API seperti
sendBeacon()
dan
requestIdleCallback()
dirancang khusus untuk menjalankan tugas
non-kritis dengan cara yang tidak
memblokir tugas-tugas
penting pengguna.
API ini adalah 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 lacak lebih dari yang Anda butuhkan
Browser mengekspos banyak data kinerja, tetapi hanya karena data itu tersedia tidak berarti Anda harus merekam dan mengirimkannya ke Google Analytics.
Misalnya, Resource Timing API menyediakan data pengaturan waktu terperinci untuk setiap resource yang dimuat di halaman Anda. Namun, kecil kemungkinannya bahwa semua data itu akan selalu atau berguna dalam sehingga meningkatkan performa pemuatan resource.
Singkatnya, jangan hanya melacak data karena ada di sana, pastikan data itu akan digunakan sebelum memakai sumber daya untuk melacaknya.