Panduan Core Web Vitals untuk Website Bisnis

Core Web Vitals adalah tiga metrik yang dipakai Google untuk mengukur pengalaman nyata pengunjung: kecepatan memuat, kestabilan tampilan, dan responsivitas. Bagi pemilik bisnis, angkanya bukan sekadar laporan teknis, tetapi cerminan berapa banyak calon pelanggan yang bertahan sampai melihat penawaran Anda.

Artikel ini membahas ambang skor yang dipakai Google, cara mengukur yang benar, penyebab umum setiap masalah, urutan perbaikan untuk tim kecil, dan kapan optimasi justru tidak perlu dipaksakan. Istilah teknis dipertahankan dalam bahasa aslinya agar mudah dicocokkan dengan laporan PageSpeed Insights atau Search Console.

• Apa itu Core Web Vitals dan kenapa penting
• Ambang skor LCP, INP, dan CLS
• Cara mengukur: field data vs lab data
• Memperbaiki LCP
• Memperbaiki INP
• Memperbaiki CLS
• Urutan prioritas dan kapan tidak perlu dikejar
• Kesimpulan dan langkah berikutnya

Apa Itu Core Web Vitals dan Kenapa Penting

Ketiga metrik ini masing-masing menjawab satu keluhan pengguna yang berbeda. Largest Contentful Paint (LCP) mengukur kecepatan memuat, yaitu kapan elemen terbesar di layar selesai tampil. Interaction to Next Paint (INP) mengukur responsivitas, yaitu berapa lama halaman merespons saat tombol ditekan atau formulir diisi. Cumulative Layout Shift (CLS) mengukur kestabilan tampilan, yaitu seberapa banyak elemen bergeser tanpa diminta.

Ketiganya sudah masuk sebagai sinyal peringkat Google lewat laporan page experience, meski bobotnya kecil dibanding relevansi konten dan kualitas backlink. Jadi memperbaiki performa tidak akan menyelamatkan halaman yang isinya tidak menjawab kebutuhan pencari. Sebaliknya, konten yang relevan tetap bisa kalah bersaing karena pengalaman membukanya buruk, terutama di mobile dengan koneksi tidak stabil. Halaman yang lambat membuat pengunjung menekan tombol kembali sebelum konten utama terlihat.

Ambang Skor LCP, INP, dan CLS

Google membagi setiap metrik menjadi tiga kategori: good, needs improvement, dan poor.

• LCP: good sampai 2,5 detik, needs improvement sampai 4 detik, poor di atas 4 detik.
• INP: good sampai 200 milidetik, needs improvement sampai 500 milidetik, poor di atas 500 milidetik.
• CLS: good sampai 0,1, needs improvement sampai 0,25, poor di atas 0,25.

Penilaian dilakukan pada persentil ke-75 dari seluruh kunjungan, bukan rata-rata. Karena itu halaman bisa terlihat cepat di laptop Anda sementara laporan lapangan tetap merah.

Catatan soal metrik responsivitas: INP menggantikan First Input Delay (FID) sebagai Core Web Vital pada 12 Maret 2024. FID hanya mengukur interaksi pertama, sedangkan INP mengukur seluruh interaksi dan mengambil nilai terburuk yang dirasakan pengguna.

Cara Mengukur: Field Data vs Lab Data

Field data berasal dari pengunjung nyata dan dikumpulkan browser mereka, sementara lab data berasal dari simulasi pada satu perangkat dan satu kondisi jaringan. Kesalahan paling umum adalah memperbaiki skor lab sampai hijau sementara field data tetap merah.

Mulai dari field data

Laporan Core Web Vitals di Search Console dan data lapangan di PageSpeed Insights bersumber dari Chrome User Experience Report, kumpulan data pengunjung nyata. Di situ Anda melihat masalah yang benar-benar dialami pengguna, lengkap dengan pengelompokan per jenis halaman dan per perangkat.

Pakai lab data untuk debugging

Setelah tahu halaman mana yang bermasalah, lab data dipakai mencari penyebabnya. Lighthouse dan panel Performance di Chrome DevTools menunjukkan elemen mana yang menjadi LCP, tugas JavaScript mana yang menahan main thread, dan elemen mana yang bergeser. Untuk pemantauan berkelanjutan, library web-vitals dari tim Chrome bisa mengirim nilai ketiga metrik dari pengunjung asli ke analytics Anda, sehingga regresi terdeteksi lebih awal.

Memperbaiki LCP: Halaman Terasa Cepat

LCP dihitung dari navigasi sampai elemen terbesar di viewport selesai dirender. Pada sebagian besar halaman elemen itu adalah gambar hero atau blok judul besar, jadi perbaikan tercepat biasanya datang dari sana.

Penyebab umum LCP merah

• Gambar hero berukuran besar dalam format lama seperti PNG atau JPEG yang belum dikompres.
• Gambar hero justru diberi lazy loading, sehingga browser sengaja menunda elemen paling penting.
• CSS dan JavaScript yang memblokir render, termasuk font dan script pihak ketiga di bagian head.
• Waktu respons server (TTFB) lambat karena hosting tanpa cache atau query database yang berat.

Langkah perbaikan

Ubah gambar ke format modern seperti WebP atau AVIF dengan ukuran yang disesuaikan lebar tampilannya, lalu pastikan gambar hero dimuat dengan prioritas tinggi dan bukan lazy. Atribut fetchpriority tinggi pada gambar hero dan preload untuk font adalah dua perubahan kecil dengan hasil cepat terasa. Dari sisi server, aktifkan caching di level aplikasi dan reverse proxy, kurangi query yang tidak perlu pada halaman terpopuler, serta pakai CDN untuk aset statis.

Memperbaiki INP: Halaman Terasa Responsif

INP mengukur jeda antara interaksi pengguna dan frame berikutnya yang tampil. Nilai buruk biasanya bukan karena animasi, melainkan pekerjaan berat JavaScript yang menumpuk di main thread sehingga browser tidak sempat menggambar ulang.

Penyebab umum INP merah

• Bundle JavaScript yang besar dan dijalankan seluruhnya saat halaman dibuka.
• Script pihak ketiga seperti widget chat, pixel iklan, atau peta yang berjalan di setiap halaman.
• Proses hydration berat pada halaman interaktif, terutama formulir dan keranjang.
• Tugas panjang (long task) yang menahan main thread lebih dari 50 milidetik saat tombol ditekan.

Langkah perbaikan

Pecah kode per halaman agar JavaScript yang tidak dipakai tidak ikut dimuat, tunda script non-kritis, dan batasi script pihak ketiga ke yang benar-benar diukur manfaatnya. Ukur INP di halaman yang paling banyak berinteraksi, bukan hanya di homepage, karena halaman formulir dan pencarian biasanya penyumbang nilai terburuk.

Memperbaiki CLS: Tampilan Tidak Melompat

CLS menghitung jumlah pergeseran tak terduga selama halaman dibuka. Perbaikannya relatif paling murah, sehingga cocok dijadikan langkah pertama.

• Sebutkan lebar dan tinggi gambar, iframe, serta video secara eksplisit supaya ruangnya sudah dipesan sejak awal.
• Sediakan ruang tetap untuk elemen yang dimuat belakangan, seperti banner atau konten embed.
• Gunakan penukaran font yang tidak mengubah ukuran teks, dan muat font lebih awal.
• Hindari menyisipkan konten di atas konten yang sudah terlihat, misalnya notifikasi yang mendorong seluruh halaman ke bawah.
• Untuk animasi, gunakan properti transform dan opacity yang tidak menggeser layout.

CLS dihitung sepanjang umur halaman, jadi pergeseran yang muncul saat pengguna menggulir tetap masuk hitungan.

Urutan Prioritas dan Kapan Tidak Perlu Dikejar

Kalau anggaran waktu terbatas, urutannya begini. Pertama, perbaiki LCP pada halaman yang paling banyak menghasilkan prospek, karena itu metrik dengan dampak terbesar pada persepsi kecepatan. Kedua, bereskan CLS dari gambar dan font, karena perbaikannya cepat dan risikonya kecil. Ketiga, baru turun ke INP dengan memangkas JavaScript dan script pihak ketiga, karena pekerjaannya paling besar dan paling sering menyentuh kode aplikasi.

Ada situasi di mana mengejar skor hijau tidak sepadan. Halaman dengan kunjungan sangat sedikit lebih baik dibiarkan, energinya lebih berharga untuk konten. Yang perlu dihindari adalah mengejar skor 100 di Lighthouse hanya demi angka, sampai mengorbankan fitur atau menambah kompleksitas yang sulit dirawat.

Kesimpulan dan Langkah Berikutnya

Core Web Vitals adalah cara mengukur pengalaman yang dirasakan langsung oleh pengunjung Anda. Ambangnya jelas: LCP sampai 2,5 detik, INP sampai 200 milidetik, dan CLS sampai 0,1 pada persentil ke-75. Perbaikannya bertahap, mulai dari field data, lalu lab data untuk mencari penyebab, lalu uji ulang pada pengunjung nyata.

Langkah paling praktis minggu ini: kompres gambar hero dan pastikan tidak di-lazy-load, beri ukuran eksplisit pada gambar dan embed, lalu audit script pihak ketiga yang jalan di setiap halaman.

Kalau website Anda sudah cukup ramai tetapi tetap terasa lambat, audit performa menyeluruh biasanya lebih hemat waktu daripada menambal satu per satu. Kami membangun dan mengoptimasi website serta web app dengan fokus pada kecepatan, SEO teknis, dan konversi. Lihat layanan yang kami kerjakan atau hubungi kami untuk membahas kondisi website Anda. Untuk konteks lebih luas soal memilih fondasi teknis, ada juga pembahasan keunggulan membangun sistem custom dibanding software pasaran di blog ini.