"Website lambat" itu subjektif — orang bisa merasa lambat karena alasan berbeda-beda. Core Web Vitals adalah cara Google membuat perasaan itu terukur: tiga angka spesifik yang menjelaskan persis di titik mana pengalaman pengguna terganggu, dan seberapa jauh dari standar yang dianggap baik.

Ringkasan cepat

Core Web Vitals mengukur tiga hal: seberapa cepat konten utama termuat (LCP), seberapa responsif halaman terhadap interaksi pengguna (INP), dan seberapa stabil tata letak saat halaman dimuat (CLS). Ketiganya resmi jadi bagian dari sinyal ranking, dan bisa dipantau gratis lewat laporan Core Web Vitals di Google Search Console.

LCPINPCLS

Kenapa Core Web Vitals Ada

Sebelum Core Web Vitals diperkenalkan, "kecepatan website" sering diukur dengan metrik yang lebih teknis dan kurang mencerminkan pengalaman nyata pengguna — misalnya waktu total halaman selesai dimuat, padahal pengguna sudah bisa mulai berinteraksi jauh sebelum itu. Google merancang tiga metrik ini supaya lebih dekat dengan apa yang benar-benar dirasakan pengguna: apakah kontennya cepat terlihat, apakah halamannya responsif saat diklik atau di-tap, dan apakah tata letaknya stabil atau malah "meloncat-loncat" saat dimuat.

MetrikBaik (Good)Perlu PerbaikanBuruk (Poor)
LCP≤ 2,5 detik2,5–4 detik> 4 detik
INP≤ 200 md200–500 md> 500 md
CLS≤ 0,10,1–0,25> 0,25

LCP: Largest Contentful Paint

LCP mengukur berapa lama elemen konten terbesar di layar (biasanya gambar hero, video, atau blok teks besar) selesai ditampilkan sejak halaman mulai dimuat. Ini jadi proxy untuk pertanyaan paling dasar pengguna: "kapan saya bisa mulai melihat isi halaman ini?"

Penyebab LCP lambat yang paling umum: gambar berukuran besar yang belum dikompresi, server response time yang lambat, render-blocking CSS/JavaScript, atau font kustom yang baru dimuat belakangan. Perbaikan paling berdampak biasanya justru yang paling sederhana — mengompresi gambar hero dan mengaktifkan lazy-loading untuk gambar yang berada di luar layar awal.

INP: Interaction to Next Paint

INP mengukur seberapa cepat halaman merespons setelah pengguna berinteraksi — klik tombol, tap menu, atau mengetik di kolom formulir. Metrik ini menggantikan First Input Delay (FID) karena FID hanya mengukur interaksi pertama, sementara INP memperhitungkan seluruh interaksi selama pengguna berada di halaman, sehingga lebih representatif.

INP yang buruk biasanya disebabkan oleh JavaScript yang terlalu berat berjalan di thread utama browser, sehingga browser "sibuk" dan telat merespons input pengguna. Plugin WordPress yang menambahkan banyak skrip pihak ketiga (chat widget, tracking pixel, slider animasi berat) adalah penyebab umum INP buruk di situs WordPress.

CLS: Cumulative Layout Shift

CLS mengukur seberapa banyak elemen di halaman "meloncat" posisinya secara tidak terduga saat halaman masih dimuat — misalnya tombol yang tiba-tiba turun karena iklan atau gambar di atasnya baru selesai dimuat, membuat pengguna salah klik. Skornya dihitung dari kombinasi seberapa besar area yang bergeser dan seberapa jauh pergeserannya.

Penyebab paling umum: gambar atau video tanpa atribut ukuran (width/height) yang ditentukan di awal, iklan atau embed yang dimuat belakangan tanpa ruang dicadangkan, dan font kustom yang menyebabkan teks "melompat" saat font akhirnya termuat.

Data Lab vs Data Lapangan

Satu kebingungan umum: skor Core Web Vitals bisa berbeda tergantung dari mana kamu mengukurnya.

  • Data Lab (Lighthouse) — pengukuran simulasi di kondisi terkontrol, sekali uji, bagus untuk debugging tapi tidak mencerminkan kondisi pengguna nyata
  • Data Lapangan (Field Data / CrUX) — data agregat dari pengguna nyata yang benar-benar mengunjungi halamanmu, dikumpulkan Chrome User Experience Report (CrUX), dan inilah yang benar-benar dipakai sebagai sinyal ranking

Skor bagus di Lighthouse tidak menjamin skor bagus di data lapangan — karena pengguna nyata mengakses dari berbagai perangkat dan kondisi jaringan yang jauh lebih beragam dibanding simulasi lab.

Cara Membaca Laporan di Search Console

Laporan "Core Web Vitals" di Google Search Console mengelompokkan URL ke tiga status: Baik, Perlu Perbaikan, dan Buruk — dipisah untuk perangkat mobile dan desktop. Klik salah satu kelompok status untuk melihat daftar URL yang termasuk di dalamnya beserta metrik mana yang jadi penyebabnya. Laporan ini memakai data lapangan (CrUX) dari 28 hari terakhir, sehingga perubahan yang baru dilakukan butuh waktu sebelum terlihat hasilnya di laporan.

Mitos vs Fakta seputar Core Web Vitals

MitosSkor 100 di PageSpeed Insights berarti Core Web Vitals sudah pasti lolos.
FaktaSkor performa PageSpeed dan status Core Web Vitals adalah dua hal berbeda — yang kedua pakai data lapangan, bukan cuma simulasi.
MitosCore Web Vitals adalah faktor ranking paling menentukan di atas segalanya.
FaktaIni salah satu dari ratusan sinyal ranking — relevansi konten tetap jauh lebih berpengaruh.
MitosSetelah diperbaiki sekali, skornya akan tetap baik selamanya.
FaktaMenambah plugin, gambar, atau skrip baru bisa menurunkan skor lagi kapan saja — perlu dipantau berkala.

Checklist Perbaikan Cepat

  • Kompresi dan lazy-load gambar, terutama yang berukuran besar di bagian atas halaman
  • Tentukan atribut width/height di setiap gambar dan video untuk mencegah layout shift
  • Cadangkan ruang untuk iklan/embed yang dimuat belakangan
  • Kurangi atau tunda pemuatan skrip pihak ketiga yang tidak esensial
  • Cek laporan Core Web Vitals di Search Console secara berkala, bukan cuma sekali
#CoreWebVitals#LCP#INP#CLS#PerformaWebsite
RF

Reza Firmansyah

Technical SEO Specialist, 5 tahun

Menangani audit teknis dan performa halaman untuk situs berskala menengah. Artikel ini ditinjau ulang terakhir 16 Juli 2026.

Sumber Rujukan Artikel Ini

  • web.dev — dokumentasi resmi Core Web Vitals
  • Google Search Central — dokumentasi laporan Core Web Vitals di Search Console
  • Chrome User Experience Report (CrUX) — metodologi pengumpulan data lapangan
  • web.dev — dokumentasi transisi dari FID ke INP
  • Data internal DELHI — temuan audit performa klien Reza Firmansyah