Website bisa mendapat nilai tinggi di Lighthouse, tetapi tetap terasa lambat bagi sebagian pengunjung. Situasi ini bukan selalu berarti salah satu alatnya keliru. Sering kali, keduanya sedang mengukur hal yang berbeda: Lighthouse menguji halaman dalam kondisi yang dikendalikan, sedangkan data lapangan melihat pengalaman pengguna nyata dengan perangkat, jaringan, lokasi, dan kebiasaan yang beragam.
Memahami perbedaan ini penting karena optimasi website tidak seharusnya berhenti pada mengejar skor 90 atau 100. Tujuan sebenarnya adalah membuat halaman cepat dibuka, nyaman disentuh, dan stabil digunakan oleh sebanyak mungkin pengunjung.
Lab data dan field data: dua cara melihat masalah yang sama
Lab data atau data sintetis dikumpulkan dalam lingkungan pengujian tertentu. Lighthouse, misalnya, menjalankan simulasi dengan perangkat, koneksi, dan lokasi yang telah ditentukan. Karena kondisinya relatif konsisten, data ini sangat berguna untuk mencari sumber masalah dan membandingkan dampak perubahan kode.
Sementara itu, field data berasal dari pengalaman pengguna nyata. Data ini juga sering disebut Real User Monitoring atau RUM. Pengunjung mungkin memakai ponsel kelas bawah, jaringan seluler yang tidak stabil, browser yang berbeda, atau berada jauh dari server. Semua kondisi tersebut dapat mengubah hasil yang mereka rasakan.
Google menggunakan data dari Chrome User Experience Report atau CrUX untuk menggambarkan pengalaman pengguna Chrome yang memenuhi kriteria tertentu. Namun, CrUX bukan rekaman setiap pengunjung website. Karena itu, data dari pengguna sendiri biasanya lebih relevan untuk mengetahui siapa yang mengalami masalah dan pada halaman mana masalah tersebut terjadi.
Mengapa angkanya bisa sangat berbeda?
1. Perangkat pengunjung tidak sama
Pengujian lokal di laptop modern mungkin menunjukkan JavaScript berjalan cepat. Namun, skrip yang sama bisa membuat ponsel dengan prosesor lebih lambat sibuk selama beberapa detik. Dampaknya paling terasa pada INP, yaitu ukuran seberapa cepat halaman merespons klik, ketukan, atau input pengguna.
INP yang baik berada di atau di bawah 200 milidetik pada persentil ke-75. Jika kode JavaScript terlalu banyak, event handler terlalu berat, atau proses rendering dilakukan sekaligus, tombol dapat terasa tidak merespons meskipun halaman sudah selesai dimuat.
2. Koneksi dan lokasi memengaruhi waktu tunggu
Pengujian dari jaringan kantor atau Wi-Fi cepat tidak selalu mewakili pengunjung yang membuka website melalui jaringan seluler. Jarak pengguna ke server, waktu membangun koneksi, proses DNS, dan ukuran respons HTML dapat memengaruhi LCP atau Largest Contentful Paint.
LCP mengukur kapan konten utama halaman terlihat. Patokan baiknya adalah 2,5 detik atau kurang pada persentil ke-75. Jika gambar utama baru ditemukan browser setelah beberapa file CSS dan JavaScript selesai diproses, hasil LCP di dunia nyata bisa lebih buruk daripada hasil pengujian lokal.
3. Cache membuat kunjungan kedua terasa berbeda
Pengunjung baru biasanya belum memiliki aset seperti CSS, font, atau gambar di cache browser. Sebaliknya, pengunjung yang sudah beberapa kali membuka website mungkin mendapatkan pengalaman lebih cepat. Lighthouse yang menjalankan pengujian tertentu dapat lebih dekat dengan kondisi kunjungan pertama, sedangkan data lapangan mencampur kunjungan baru dan kunjungan berulang.
Perbedaan ini bukan alasan untuk mengabaikan pengujian cold load. Kunjungan pertama tetap penting, terutama untuk halaman landing, iklan, hasil pencarian, dan halaman kampanye yang banyak menerima pengunjung baru.
4. Isi halaman tidak selalu sama
Pengguna mobile mungkin melihat menu, banner, atau gambar yang berbeda dari pengguna desktop. Website yang memakai personalisasi, cookie banner, iklan, rekomendasi produk, atau konten dinamis juga bisa menghasilkan elemen terbesar yang berbeda.
Hal ini dapat mengubah LCP. Pada satu pengujian, elemen terbesar mungkin berupa gambar hero. Pada pengunjung lain, elemen terbesar bisa berupa judul artikel atau blok promosi yang muncul setelah permintaan tambahan selesai.
Jangan terpaku pada satu angka
Data pengguna bukan sekadar satu skor yang berlaku untuk semua orang. Field data menggambarkan distribusi pengalaman. Sebagian pengunjung mungkin mendapat LCP 1,5 detik, sementara kelompok lain mengalami 5 detik.
Karena itu, Core Web Vitals biasanya dinilai menggunakan persentil ke-75. Sederhananya, target tersebut berusaha memastikan setidaknya sebagian besar kunjungan berada dalam kategori baik, bukan hanya mengejar hasil terbaik dari beberapa pengujian.
Selain LCP dan INP, perhatikan juga CLS atau Cumulative Layout Shift. CLS mengukur seberapa sering tata letak bergeser secara tiba-tiba. Nilai 0,1 atau kurang dianggap baik. Penyebab umum CLS antara lain gambar tanpa dimensi, iklan yang muncul tanpa ruang yang disiapkan, embed dinamis, dan font yang mengubah ukuran teks setelah halaman tampil.
Alur pemeriksaan yang lebih masuk akal
- Mulai dari data lapangan. Periksa PageSpeed Insights, Search Console, atau RUM untuk mengetahui apakah pengguna nyata mengalami masalah. Lihat perbedaan mobile dan desktop, bukan hanya nilai keseluruhan.
- Kelompokkan masalahnya. Cari tahu apakah persoalan utama berada pada LCP, INP, CLS, waktu respons server, gambar, JavaScript, atau elemen pihak ketiga.
- Gunakan Lighthouse untuk diagnosis. Setelah mengetahui area yang bermasalah, jalankan beberapa pengujian untuk melihat file, request, dan proses yang mungkin menjadi penyebab.
- Uji halaman yang benar-benar penting. Jangan hanya menguji beranda. Periksa halaman artikel, halaman produk, formulir, checkout, dan halaman yang paling banyak menerima trafik.
- Bandingkan sebelum dan sesudah. Simpan hasil pengujian dengan kondisi yang serupa. Satu angka yang membaik sekali belum cukup untuk menyimpulkan bahwa perubahan sudah aman.
- Monitor setelah rilis. Plugin baru, tag iklan, perubahan tema, atau fitur personalisasi dapat membuat performa mundur beberapa minggu kemudian.
Apa artinya bagi kita?
Jika Lighthouse bagus tetapi pengguna masih mengeluh, jangan langsung menambah plugin cache atau mengecilkan semua gambar. Pertanyaan yang lebih berguna adalah: siapa yang lambat, pada halaman apa, menggunakan perangkat apa, dan saat melakukan tindakan apa?
Misalnya, laporan lapangan menunjukkan INP buruk terutama pada halaman katalog mobile. Pemeriksaan lebih lanjut menemukan filter produk menjalankan pencarian dan menyusun ulang ratusan elemen setiap kali tombol disentuh. Solusinya mungkin bukan CDN, melainkan mengurangi pekerjaan JavaScript, membatasi jumlah elemen yang dirender, atau menunda proses yang tidak penting.
Begitu pula jika LCP buruk hanya pada pengunjung dari wilayah tertentu. Masalahnya bisa berkaitan dengan lokasi server, ukuran gambar utama, atau waktu respons backend. Optimasi menjadi lebih tepat sasaran ketika keputusan dibuat dari kombinasi data nyata dan alat diagnosis.
Yang bisa dilakukan sekarang
- Catat tiga halaman dengan trafik terbesar dan uji versi mobile-nya.
- Bandingkan hasil Lighthouse dengan data field dari PageSpeed Insights atau Search Console.
- Periksa apakah gambar utama langsung terlihat di HTML awal dan memiliki ukuran yang jelas.
- Telusuri JavaScript pihak ketiga yang tidak penting untuk tampilan awal.
- Ukur interaksi penting seperti pencarian, filter, menu, dan pengiriman formulir, bukan hanya waktu buka halaman.
- Buat pemantauan berkala agar regresi performa terlihat sebelum keluhan bertambah.
Skor lab tetap berguna, tetapi ia lebih tepat diperlakukan sebagai alat diagnosis, bukan rapor final seluruh pengguna. Website yang sehat membutuhkan dua sudut pandang: pengujian terkontrol untuk menemukan penyebab dan data lapangan untuk memastikan perbaikannya benar-benar terasa.
Sumber & bacaan lebih lanjut
- Core Web Vitals workflows with Google tools
- Why lab and field data can be different
- Getting started with measuring Web Vitals
- Interaction to Next Paint (INP)
- CrUX methodology
– Rio Yotto @rioyotto