>
technical-seo

Core Web Vitals: LCP, INP, dan CLS — Cara Mengukur dan Memperbaikinya

DN

Dyaksa Naya

25 Juli 2026

4 min read
#seo #technical seo
Core Web Vitals: LCP, INP, dan CLS — Cara Mengukur dan Memperbaikinya

Core Web Vitals adalah tiga metrik performa yang digunakan Google untuk mengukur pengalaman pengguna secara teknis — seberapa cepat halaman dimuat, seberapa responsif terhadap interaksi, dan seberapa stabil tata letaknya. Sejak 2021, Google mengintegrasikan metrik ini sebagai faktor ranking dalam penilaian Page Experience.

Memahami definisi dasarnya sudah dibahas di artikel technical SEO. Artikel ini fokus lebih dalam pada cara mengukur dan memperbaiki setiap metrik secara konkret.

LCP — Largest Contentful Paint

Apa yang diukur: Waktu yang dibutuhkan sejak halaman mulai dimuat hingga elemen konten terbesar muncul di viewport — biasanya gambar hero, foto produk utama, atau blok teks yang paling dominan.

Threshold: Di bawah 2.5 detik = Good. 2.5–4 detik = Needs Improvement. Di atas 4 detik = Poor.

Cara mengukur:

  • PageSpeed Insights (pagespeed.web.dev) — tampilkan data lab (simulasi) dan field data (dari pengguna nyata via CrUX)
  • Google Search Console → laporan Core Web Vitals → lihat distribusi URL berdasarkan status
  • Chrome DevTools → tab Performance → rekam loading halaman, cari elemen LCP

Penyebab LCP lambat yang paling umum:

  • Gambar hero berukuran terlalu besar atau belum dikompres
  • Server response time lambat (TTFB tinggi)
  • Resource penting diblokir oleh CSS atau JS yang tidak perlu
  • Font loading yang lambat menyebabkan teks tidak tampil

Cara memperbaiki: Prioritaskan elemen yang akan menjadi LCP dengan atribut fetchpriority="high":

<img src="hero.webp" fetchpriority="high" alt="...">

Preload resource LCP di <head> untuk gambar yang sudah diketahui:

<link rel="preload" as="image" href="hero.webp">

Konversi gambar ke format WebP atau AVIF — ukuran file lebih kecil dengan kualitas setara. Pastikan server hosting mendukung HTTP/2 dan kompresi Brotli untuk mempercepat transfer.

INP — Interaction to Next Paint

Apa yang diukur: Responsivitas halaman terhadap interaksi pengguna — berapa lama dari klik, tap, atau keystroke pertama hingga browser menampilkan respons visual berikutnya. INP menggantikan FID (First Input Delay) sejak Maret 2024.

Threshold: Di bawah 200 ms = Good. 200–500 ms = Needs Improvement. Di atas 500 ms = Poor.

Perbedaan INP vs FID: FID hanya mengukur delay pertama kali pengguna berinteraksi. INP mengukur semua interaksi selama halaman dibuka dan mengambil nilai terburuk (persentil ke-98). INP jauh lebih representatif untuk website dengan banyak interaksi seperti form, filter, atau menu dinamis.

Cara mengukur:

  • PageSpeed Insights → section “Diagnose Performance Issues” → cari INP
  • Chrome DevTools → tab Performance Insights → interaksi yang lambat akan ditandai

Penyebab INP buruk:

  • JavaScript berat yang memblokir main thread selama interaksi
  • Event handlers yang tidak efisien atau memicu re-render besar
  • Third-party scripts (chat widget, analytics, ads) yang mengambil main thread

Cara memperbaiki: Identifikasi long tasks di DevTools — tugas JavaScript yang memakan lebih dari 50ms di main thread. Pecah long tasks menggunakan scheduler.yield() atau setTimeout() untuk memberikan kesempatan browser merespons interaksi:

async function processLargeData() {
  for (const item of items) {
    process(item);
    await scheduler.yield(); // yield ke browser setiap iterasi
  }
}

Tinjau dan kurangi third-party scripts yang tidak kritis — muat mereka secara lazy atau tunda hingga setelah halaman interaktif.

CLS — Cumulative Layout Shift

Apa yang diukur: Seberapa banyak konten bergeser secara tak terduga saat halaman dimuat atau saat pengguna berinteraksi. Setiap kali elemen bergeser, score CLS bertambah — semakin besar pergeserannya, semakin tinggi skornya.

Threshold: Di bawah 0.1 = Good. 0.1–0.25 = Needs Improvement. Di atas 0.25 = Poor.

Cara mengukur:

  • PageSpeed Insights → section “Avoid large layout shifts”
  • Chrome DevTools → tab Performance → rendering area → aktifkan “Layout Shift Regions” untuk melihat area yang bergeser (ditandai warna biru)

Penyebab CLS tinggi yang paling umum:

  • Gambar tanpa deklarasi dimensi — browser tidak tahu ruang yang perlu disiapkan
  • Iklan atau embed yang muncul terlambat dan mendorong konten di bawahnya
  • Font web yang menyebabkan FOUT (Flash of Unstyled Text) — teks bergeser saat font selesai dimuat
  • Konten yang diinjeksikan secara dinamis di atas konten yang sudah ada

Cara memperbaiki: Deklarasikan width dan height untuk semua elemen media:

<img src="produk.webp" width="800" height="600" alt="...">

Untuk iklan atau embed, sediakan placeholder dengan ukuran yang sudah ditetapkan agar ruangnya sudah teralokasi sebelum konten dimuat:

.ad-container {
  min-height: 250px; /* sesuaikan dengan ukuran iklan */
}

Gunakan font-display: optional untuk font yang tidak kritis, atau font-display: swap dengan preload font agar transisi lebih mulus.

Cara Memantau Core Web Vitals Secara Berkelanjutan

PageSpeed Insights dan Chrome DevTools memberikan data lab (simulasi). Untuk data dari pengguna nyata, gunakan Google Search Console → Core Web Vitals — laporan ini menggunakan Chrome User Experience Report (CrUX) yang mengaggregasi data dari pengguna Chrome secara anonim.

Perhatikan perbedaan antara keduanya: data lab bisa “Good” sementara data field “Poor” jika website memiliki banyak third-party scripts yang baru aktif setelah user berinteraksi.

Pantau tren dari waktu ke waktu menggunakan GSC — kenaikan atau penurunan yang tiba-tiba setelah deploy baru adalah sinyal untuk investigasi lebih lanjut. Gunakan checklist technical SEO sebagai panduan verifikasi berkala setelah setiap update signifikan.

Jika kamu butuh audit Core Web Vitals dan optimasi performa website secara menyeluruh, jasa SEO bikinwebjogja siap membantu.

Artikel Terkait

Bagikan Artikel

Butuh Bantuan dengan Website Kamu?

Tim ahli kami siap membantu mewujudkan website profesional untuk bisnis Kamu