Core Web Vitals: pengertian LCP, INP, dan CLS, ambang nilainya, dan cara memperbaikinya

Core Web Vitals adalah tiga metrik dari Google untuk mengukur pengalaman nyata pengunjung saat membuka sebuah halaman. Ketiganya menjawab pertanyaan yang sangat manusiawi: apakah konten utama cepat terlihat, apakah halaman cepat merespons ketika diklik, dan apakah tata letaknya tidak meloncat loncat saat dibaca.

Banyak pemilik situs mengenal istilah ini dari skor merah di PageSpeed Insights, lalu panik. Padahal yang dinilai Google bukan skor tunggal, melainkan tiga angka spesifik dengan ambang yang jelas. Panduan ini membahas arti tiap metrik, ambang nilainya, beda data lapangan dan data lab, cara mengecek, penyebab nilai buruk, dan urutan perbaikan yang masuk akal. Kalau Anda baru mulai, baca juga dasar technical SEO agar konteksnya utuh.

Pengertian Core Web Vitals

Google memakai istilah Web Vitals untuk sekumpulan sinyal kualitas pengalaman pengguna di web. Dari kumpulan itu, tiga metrik dipilih sebagai inti dan disebut Core Web Vitals. Dokumentasi Google Search Central menyebut ketiganya mengukur pengalaman nyata pengguna untuk kinerja pemuatan, interaktivitas, dan stabilitas visual halaman.

Tiga metrik tersebut adalah:

1. Largest Contentful Paint (LCP), mengukur kapan elemen konten terbesar di layar selesai ditampilkan. Ini mewakili kesan “halamannya sudah muncul”.
2. Interaction to Next Paint (INP), mengukur seberapa cepat halaman menampilkan respons setelah pengunjung mengetuk, mengeklik, atau menekan tombol.
3. Cumulative Layout Shift (CLS), mengukur seberapa banyak elemen bergeser tanpa diduga selama halaman dibuka.

Yang membuat Core Web Vitals berbeda dari skor kecepatan biasa adalah sumber datanya. Penilaian resmi memakai data dari pengguna Chrome sungguhan, bukan simulasi di satu komputer. Artinya, situs yang terasa cepat di laptop kantor Anda bisa tetap bernilai buruk kalau sebagian besar pengunjung memakai ponsel kelas menengah dengan jaringan seluler.

Daftar metrik ini juga bisa berubah. web.dev menjelaskan bahwa metrik yang sudah stabil pun bisa dipensiunkan dan diganti metrik yang lebih tepat. Itulah yang terjadi pada First Input Delay (FID), yang digantikan INP pada 2024.

Ambang nilai LCP, INP, dan CLS

Setiap metrik punya tiga kategori: baik, perlu perbaikan, dan buruk. Angka di tabel berikut diambil dari artikel web.dev tentang cara ambang Core Web Vitals ditetapkan.

Ada satu detail yang sering terlewat: nilai itu tidak dibaca dari satu kunjungan. web.dev menyarankan memakai persentil ke-75 dari seluruh pemuatan halaman, dipisahkan antara ponsel dan desktop. Sebuah halaman dianggap lolos bila ketiga metrik memenuhi ambang baik pada persentil itu.

Dalam bahasa sederhana, kalau minimal 75 persen kunjungan mendapat LCP 2,5 detik atau lebih cepat, LCP halaman itu dinilai baik. Sebaliknya, cukup 25 persen kunjungan yang melewati ambang buruk untuk membuat halaman dinilai buruk. Persentil ini dipilih supaya situs tidak hanya cepat untuk pengunjung dengan perangkat dan jaringan terbaik.

Penjelasan tiap metrik dengan bahasa sederhana

Angka saja tidak cukup untuk memperbaiki. Anda perlu tahu apa yang sebenarnya diukur tiap metrik, karena penyebab dan perbaikannya berbeda.

LCP: kapan konten utama terlihat

LCP mencatat waktu ketika elemen terbesar di area layar pertama selesai ditampilkan. Menurut web.dev, elemen yang dihitung antara lain gambar, poster atau bingkai pertama video, elemen dengan gambar latar yang dimuat lewat CSS, dan blok teks. Pada kebanyakan halaman usaha, elemen LCP adalah gambar hero atau judul besar di bagian atas.

Karena itu, LCP buruk hampir selalu berkaitan dengan empat hal: server yang lambat merespons, gambar hero yang terlalu berat, berkas CSS atau JavaScript yang menahan tampilan, dan gambar penting yang baru dimuat belakangan.

INP: seberapa cepat halaman merespons

INP mengamati semua klik, ketukan, dan penekanan tombol selama kunjungan, lalu melaporkan salah satu interaksi paling lambat. web.dev membagi satu interaksi menjadi tiga bagian: jeda input sebelum kode penanganan berjalan, durasi pemrosesan kode itu, dan jeda presentasi sampai layar berikutnya digambar.

Penyebab paling umum INP buruk adalah tugas JavaScript yang panjang di utas utama. Ketika browser sedang sibuk menjalankan skrip pihak ketiga, misalnya widget obrolan atau tag pelacak yang menumpuk, klik pengunjung harus antre. Pengunjung merasakannya sebagai tombol yang “macet”.

CLS: seberapa stabil tata letak

CLS menjumlahkan pergeseran elemen yang terjadi tanpa diminta pengunjung. Contoh klasiknya: Anda hendak mengetuk tautan, lalu sebuah banner muncul di atasnya dan Anda malah mengetuk iklan. web.dev menyebut penyebab umum CLS adalah gambar atau video tanpa ukuran, font yang dirender lebih besar atau lebih kecil dari pengganti sementaranya, dan konten yang disisipkan secara dinamis.

Pergeseran yang terjadi dalam 500 milidetik setelah interaksi pengguna tidak dihitung, karena pergeseran itu memang diharapkan. Membuka menu, misalnya, tidak menambah CLS.

Data lapangan dan data lab, jangan tertukar

Sumber kebingungan terbesar soal Core Web Vitals adalah dua jenis data yang sering tampil berdampingan.

Data lapangan adalah penilaian. Data lab adalah alat diagnosis. Kalau situs Anda masih baru atau kunjungannya sedikit, data lapangan sering belum tersedia, dan PageSpeed Insights akan menampilkan keterangan tidak ada data di bagian pengalaman pengguna nyata. Dalam kondisi itu, data lab menjadi pegangan utama sementara.

Perlu diingat juga bahwa skor Performance di PageSpeed Insights bukan Core Web Vitals. Skor itu adalah gabungan beberapa metrik lab. Halaman bisa berskor 70 tetapi lolos Core Web Vitals di data lapangan, atau sebaliknya.

Cara mengecek Core Web Vitals situs Anda

Ada tiga tempat yang paling praktis, masing masing dengan kegunaan berbeda.

1. Laporan Core Web Vitals di Search Console

Ini tempat pertama untuk melihat kondisi seluruh situs. Menurut halaman bantuan Search Console, laporan ini mengelompokkan performa URL berdasarkan status (Poor, Need improvement, Good), jenis metrik, dan grup URL, yaitu kumpulan halaman yang mirip. Status sebuah grup mengikuti metrik dengan kinerja paling buruk. Jadi kalau CLS sebuah grup buruk tetapi INP-nya baik, status grup itu tetap buruk.

Laporan dipisah untuk ponsel dan desktop, dan angka tiap grup menunjukkan nilai yang dicapai 75 persen permintaan halaman dalam 28 hari terakhir. Hanya URL yang terindeks yang bisa muncul. Kalau Anda belum menyiapkan Search Console, ikuti panduan Google Search Console lebih dulu.

2. PageSpeed Insights untuk satu URL

PageSpeed Insights menampilkan dua hal sekaligus: data lapangan bila tersedia, dan hasil uji lab Lighthouse. Gunakan untuk memeriksa satu halaman yang bermasalah, misalnya contoh URL dari laporan Search Console. Cara membaca tiap bagiannya sudah kami bahas di panduan PageSpeed Insights.

Tangkapan layar di bawah adalah hasil uji kami terhadap beranda situs ini. Di bagian atas, data pengguna nyata belum tersedia karena situsnya masih baru, sehingga yang terlihat hanya angka lab.

3. Chrome DevTools untuk mencari penyebab

Panel Performance di Chrome DevTools menampilkan nilai LCP, INP, dan CLS saat Anda berinteraksi langsung dengan halaman. Alat ini paling berguna untuk developer yang perlu menemukan elemen LCP yang sebenarnya, skrip yang membuat klik terasa lambat, atau elemen yang bergeser.

Penyebab umum nilai buruk dan cara memperbaikinya

Perbaikan selalu dimulai dari metrik yang paling buruk, karena metrik itulah yang menentukan status grup URL. Tabel berikut merangkum penyebab yang paling sering kami temui di situs usaha dan langkah perbaikannya.

Untuk situs WordPress, banyak masalah ini datang dari tema yang berat dan plugin yang menumpuk. Mengurangi plugin sering lebih efektif daripada menambah plugin optimasi baru. Pembahasan lebih luas ada di WordPress SEO.

Seberapa besar pengaruh Core Web Vitals ke SEO

Google Search Central menulis bahwa pemilik situs sangat disarankan mencapai Core Web Vitals yang baik untuk keberhasilan di Search, dan bahwa hal ini, bersama aspek pengalaman halaman lainnya, selaras dengan apa yang ingin dihargai sistem peringkat utama Google. Kalimat itu penting dibaca dengan tenang.

Pertama, Core Web Vitals bukan faktor yang mengalahkan relevansi. Halaman cepat yang tidak menjawab pencarian tetap kalah dari halaman yang lebih lambat tetapi isinya tepat. Kedua, manfaat terbesarnya sering justru di luar ranking: pengunjung yang tidak menunggu lama dan tidak salah klik lebih mungkin membaca sampai habis dan menghubungi Anda.

Karena itu, kami menempatkan Core Web Vitals sebagai bagian dari kesehatan teknis, bukan proyek utama. Pastikan dulu halaman penting terindeks, judul dan isinya relevan, lalu bereskan metrik yang buruk. Kerangka berpikir ini sama dengan yang kami pakai di strategi SEO dan SEO analysis.

Urutan kerja yang masuk akal untuk situs usaha

Kalau Anda bukan developer dan ingin tahu harus mulai dari mana, ikuti urutan berikut:

1. Buka laporan Core Web Vitals di Search Console dan catat grup URL yang berstatus buruk di ponsel. Ponsel biasanya lebih bermasalah dan lebih banyak dipakai pengunjung.
2. Ambil satu URL contoh dari grup terburuk, lalu uji di PageSpeed Insights untuk melihat metrik mana yang gagal.
3. Perbaiki penyebab yang paling sederhana dulu: ukuran gambar hero, gambar tanpa dimensi, dan skrip pihak ketiga yang tidak benar benar dipakai.
4. Uji ulang di lab untuk memastikan perbaikan bekerja sebelum menunggu data lapangan.
5. Jalankan validasi perbaikan di laporan Search Console, lalu pantau selama beberapa minggu karena data lapangan memakai jendela 28 hari.
6. Jaga agar tidak mundur. Setiap kali menambah plugin, widget, atau tag pelacak baru, uji ulang halaman utama.

Kalau situs Anda punya ribuan halaman dengan pola sama, seperti halaman produk atau halaman kota, perbaikan di template biasanya memperbaiki ribuan URL sekaligus. Pola halaman semacam ini juga dibahas di programmatic SEO.

Kesalahan yang sering terjadi

Beberapa kebiasaan membuat usaha memperbaiki Core Web Vitals sia sia:

• Mengejar skor 100 di PageSpeed Insights. Skor lab berubah setiap kali diuji dan bukan penilaian resmi. Fokus pada status data lapangan.
• Menguji dari desktop saja. Penilaian dipisah antara ponsel dan desktop, dan ponsel hampir selalu lebih berat.
• Memberi lazy load pada gambar hero. Lazy load cocok untuk gambar di bawah layar, tetapi gambar yang menjadi elemen LCP justru harus dimuat secepat mungkin.
• Menumpuk plugin optimasi. Dua plugin cache atau minifikasi yang bertabrakan sering memperburuk keadaan.
• Lupa bahwa perubahan butuh waktu. Karena data lapangan dihitung dari 28 hari, laporan tidak langsung hijau sehari setelah perbaikan.

Hal kecil lain yang sering terlupa: atribut gambar dan struktur halaman yang rapi juga membantu mesin pencari memahami isi. Untuk itu, pelajari juga SEO on page, schema markup, dan sitemap.

Kesimpulan

Core Web Vitals adalah cara Google mengukur tiga hal yang langsung dirasakan pengunjung: konten utama cepat terlihat (LCP 2,5 detik atau kurang), halaman cepat merespons (INP 200 milidetik atau kurang), dan tata letak tidak meloncat (CLS 0,1 atau kurang), semuanya pada persentil ke-75 kunjungan nyata. Pakai Search Console untuk menilai, PageSpeed Insights dan DevTools untuk mencari penyebab, lalu perbaiki dari metrik yang paling buruk.

Kalau Anda ingin memahami gambaran besar sebelum masuk ke detail teknis, mulai dari apa itu SEO dan cara kerja SEO. Butuh orang lain membaca kondisi situs Anda? Ceritakan situasinya lewat halaman kontak.