PageSpeed Insights bisa menampilkan dua cerita sekaligus. Angka pengujian saat ini terlihat baik, tetapi pengalaman pengguna masih bermasalah. Atau hasil lab buruk sementara data pengguna nyata terlihat sehat. Sebelum meminta developer mengganti hosting, pastikan kedua angka memang menjawab pertanyaan yang sama.
Panduan ini membantu kamu membaca bukti performa dan menyusun prioritas. Kita perlu mengetahui siapa yang diukur, halaman mana yang diwakili, dan kapan pengalaman tersebut terjadi. Skor tanpa konteks mudah menghasilkan pekerjaan yang salah sasaran.
Pisahkan pengamatan pengguna dan eksperimen lab
Data lapangan menggambarkan pengalaman kunjungan nyata yang tercakup dalam pengumpulan data. Data lab berasal dari pengujian dengan kondisi tertentu. Lab berguna untuk mereproduksi masalah dan menelusuri penyebab, sementara data lapangan membantu menilai luas pengalaman yang terjadi.
PageSpeed Insights memakai CrUX untuk data pengguna selama periode 28 hari terakhir. Ketika data sebuah URL tidak mencukupi, tampilannya dapat menggunakan data origin. Origin mewakili cakupan host dengan protokol dan port yang sama, bukan otomatis hanya halaman yang kamu masukkan. Dokumentasi PageSpeed Insights.
Karena itu, tulis cakupan data sebelum menulis kesimpulan. Keterangan “mobile, origin” tidak boleh berubah menjadi “halaman produk A gagal di mobile” tanpa pemeriksaan lanjutan.
Baca metrik, bukan hanya skor besar
Tiga Core Web Vitals adalah LCP untuk pemuatan konten utama, INP untuk respons interaksi, dan CLS untuk kestabilan tampilan. Ambang baik adalah LCP paling lama 2,5 detik, INP paling lama 200 milidetik, serta CLS paling tinggi 0,1. Penilaiannya menggunakan persentil ke-75, dengan perhatian pada segmen perangkat. Penjelasan Web Vitals.
Persentil bukan rata-rata. Nilai yang baik pada kunjungan tercepat tidak membuktikan mayoritas pengalaman sudah memadai. Sebaliknya, satu percobaan lab yang lambat belum membuktikan seluruh pengunjung mengalami masalah yang sama.
Skor Performance di Lighthouse juga bukan sinonim dari kelulusan Core Web Vitals. Simpan metrik individual dan kondisi pengujiannya agar perubahan bisa dibandingkan secara masuk akal.
Contoh: origin buruk, halaman yang diuji cepat
Bayangkan toko alat gambar dengan dua template. Halaman artikel relatif ringan. Halaman produk memakai galeri besar dan pemilih varian. Ini contoh ilustratif, bukan data website tertentu.
Kamu menguji artikel dan mendapatkan LCP lab 1,8 detik. Bagian data pengguna menampilkan LCP 3,4 detik dengan label origin. Kesimpulan “artikel ini pasti lambat” belum didukung bukti. Masalah bisa dominan pada halaman produk atau pada kondisi kunjungan yang tidak direplikasi lab.
Gunakan tabel kerja berikut:
| Sampel | Cakupan data lapangan | Hasil lab | Pemeriksaan berikutnya |
|---|---|---|---|
| Artikel panduan | Origin | LCP 1,8 detik | Cari sampel artikel lain dan kondisi kunjungan |
| Detail produk | URL, bila tersedia | Belum diuji | Uji galeri dan resource utama |
| Kategori | Tidak tersedia | Belum diuji | Ambil sampel template, jangan beri status lulus |
Tidak ada data berarti belum diketahui. Mengubahnya menjadi nilai nol atau warna hijau akan menyesatkan laporan.
Susun baseline yang dapat diulang
Pilih URL yang mewakili template dan fungsi berbeda. Catat perangkat, tanggal, versi aplikasi, kondisi cache, serta alat yang digunakan. Untuk lab, jalankan beberapa pengulangan dalam kondisi konsisten dan perhatikan variasinya.
Simpan satu lembar dengan kolom berikut:
- URL dan nama template.
- Sumber data: CrUX, pengukuran pengguna sendiri, atau lab.
- Cakupan: URL atau origin, mobile atau desktop.
- Periode pengamatan dan tanggal rilis terakhir.
- Metrik bermasalah serta bukti diagnosisnya.
- Perubahan yang diuji dan hasil verifikasi.
Pengukuran pengguna sendiri membutuhkan instrumentasi yang benar. Jangan menganggap memasang Google Analytics otomatis menyediakan semua rincian Web Vitals yang kamu butuhkan.
Periksa pola ketika hasil bertentangan
Jika lab baik tetapi lapangan buruk, periksa perbedaan perangkat, koneksi, lokasi, halaman dalam origin, dan interaksi setelah halaman dimuat. Pengujian awal yang singkat bisa melewatkan pergeseran tampilan atau interaksi lambat saat pengguna membaca lebih jauh.
Jika lab buruk tetapi lapangan baik, lihat apakah skenario lab terlalu berbeda, sampelnya tidak mewakili, atau kunjungan nyata terbantu cache. Tetap periksa hambatan yang bisa direproduksi; jangan menghapusnya hanya karena agregat masih baik.
Setelah perbaikan, lab dapat menunjukkan perubahan segera. Data lapangan yang memakai jendela berjalan masih mencampurkan pengalaman sebelum dan sesudah rilis. Catat tanggal rilis dan ikuti perubahan cakupannya, tanpa menjanjikan seluruh laporan langsung berganti pada hari yang sama.
Keputusan yang berguna berbunyi spesifik: “Galeri produk menunda LCP pada pengujian mobile yang dapat diulang; perubahan prioritas gambar sudah lolos tes fungsi.” Kalimat itu memberi tim pekerjaan jelas sekaligus menjaga batas bukti.
