seokita.id

SEO teknis, riset keyword, on-page optimization untuk pasar Indonesia

Core Web Vitals 2025: Panduan Teknis untuk Situs Indonesia

by Bayu Wicaksono
Core Web Vitals 2025: Panduan Teknis untuk Situs Indonesia

Kesalahan yang Bikin Skor CWV Anda Tidak Pernah Hijau

Banyak pemilik bisnis sudah pasang Google Search Console, lihat laporan Core Web Vitals, dan berhenti di sana. Skor merah dibiarkan berminggu-minggu karena asumsinya: "itu urusan developer, bukan urusan SEO."

Padahal Google secara eksplisit memasukkan Core Web Vitals (CWV) sebagai salah satu sinyal Page Experience sejak 2021—dan di 2025, bobotnya makin terasa di niche kompetitif seperti keuangan, properti, dan e-commerce lokal. Situs dengan LCP di atas 4 detik konsisten kalah dari kompetitor yang LCP-nya di bawah 2,5 detik, bahkan ketika kontennya lebih lengkap.

Artikel ini bukan teori. Ini adalah workflow audit yang saya pakai untuk klien di niche otomotif dan keuangan—lengkap dengan tools gratis dan langkah eksekusi yang bisa Anda mulai hari ini.

Apa Itu Core Web Vitals dan Kenapa Bisnis Anda Harus Peduli

Core Web Vitals adalah tiga metrik yang Google gunakan untuk mengukur pengalaman pengguna secara teknis:

  • LCP (Largest Contentful Paint): Seberapa cepat elemen terbesar di halaman (biasanya gambar hero atau blok teks utama) muncul. Target: ≤ 2,5 detik.
  • INP (Interaction to Next Paint): Menggantikan FID sejak Maret 2024. Mengukur responsivitas situs saat pengguna klik, tap, atau ketik. Target: ≤ 200 ms.
  • CLS (Cumulative Layout Shift): Seberapa banyak elemen halaman bergeser saat loading. Target: ≤ 0,1.

Untuk pasar Indonesia, ada konteks tambahan yang krusial: mayoritas pengguna mengakses lewat mobile dengan koneksi 4G yang tidak stabil. Data dari Statcounter menunjukkan 74% traffic web Indonesia berasal dari perangkat mobile. Artinya, skor CWV desktop yang hijau tidak cukup—Anda harus fokus ke skor mobile.

Cara Audit Core Web Vitals: Dari Data Field ke Lab

Ada dua jenis data CWV yang perlu Anda pahami sebelum mulai perbaikan:

1. Field Data (Real User Monitoring) Ini data dari pengguna nyata yang dikumpulkan Chrome. Tersedia di:

  • Google Search Console → Laporan Core Web Vitals
  • PageSpeed Insights (bagian atas, berlabel "Discover what your real users are experiencing")
  • CrUX Dashboard (gratis, bisa di-filter per URL)

2. Lab Data (Simulasi) Ini simulasi di kondisi terkontrol. Berguna untuk debugging, tapi tidak langsung memengaruhi ranking.

  • PageSpeed Insights (bagian bawah)
  • Lighthouse di Chrome DevTools
  • WebPageTest.org (pilih lokasi server Jakarta untuk hasil relevan)

Prioritas audit: Mulai dari field data di Search Console. Kalau URL masuk kategori "Perlu Perbaikan" atau "Buruk", baru masuk ke lab data untuk cari penyebabnya.

Checklist Audit CWV (Urutan Eksekusi)

  • Buka Google Search Console → Pengalaman → Core Web Vitals
  • Filter laporan ke "Mobile" — ini yang relevan untuk ranking Indonesia
  • Identifikasi grup URL yang masuk kategori "Buruk" (merah) — biasanya pola template yang sama
  • Ambil satu URL perwakilan dari grup tersebut
  • Jalankan di PageSpeed Insights → catat skor LCP, INP, CLS
  • Jalankan di WebPageTest.org dengan lokasi "Singapore" (terdekat untuk Indonesia)
  • Screenshot hasil — ini baseline Anda sebelum perbaikan

Perbaikan LCP: Masalah Paling Umum di Situs Indonesia

Dari pengalaman audit 30+ situs lokal, penyebab LCP lambat yang paling sering saya temukan:

1. Gambar Hero Tidak Di-preload

Gambar hero (banner utama) sering jadi elemen LCP. Masalahnya, browser baru "tahu" gambar ini perlu di-load setelah parsing CSS dan HTML selesai—terlambat.

Solusi: Tambahkan tag <link rel="preload"> di <head> untuk gambar hero:

<link rel="preload" as="image" href="/images/hero-banner.webp" fetchpriority="high">

Tambahkan atribut fetchpriority="high" pada tag <img> gambar hero juga.

2. Hosting Lambat atau Server di Luar Indonesia

Ini yang sering diremehkan. Kalau server Anda di Singapura atau Amerika, TTFB (Time to First Byte) bisa 600ms+ untuk pengguna Indonesia. TTFB yang tinggi otomatis mendorong LCP ke atas.

Cek TTFB Anda: Di WebPageTest, lihat metrik "Time to First Byte". Target: di bawah 800ms untuk mobile Indonesia.

Solusi: Pindah ke hosting dengan data center Indonesia (IDCloudHost, Niagahoster dengan server Jakarta, atau Cloudflare dengan cache agresif). Jika Anda ingin memahami lebih dalam tentang performa hosting, this guide on uptime hosting Indonesia menyediakan perbandingan data real dari berbagai penyedia.

3. Gambar Belum Dikonversi ke WebP

Format JPEG dan PNG masih dominan di situs Indonesia. WebP rata-rata 25–35% lebih kecil dengan kualitas visual yang sama.

Tools konversi:

  • Squoosh.app (gratis, browser-based)
  • Plugin Imagify atau ShortPixel kalau pakai WordPress
  • CLI: cwebp -q 80 input.jpg -o output.webp

Perbaikan INP: Metrik Baru yang Sering Diabaikan

INP menggantikan FID sejak Maret 2024, dan banyak situs yang belum sadar mereka punya masalah di sini. INP mengukur semua interaksi selama sesi pengguna, bukan hanya interaksi pertama.

Penyebab INP buruk yang paling umum:

  1. JavaScript pihak ketiga yang berat — tracking pixel, live chat, pop-up marketing. Setiap script ini "memblokir" main thread browser.
  2. Long Tasks — JavaScript yang berjalan lebih dari 50ms tanpa jeda. Browser tidak bisa merespons input pengguna selama task ini berjalan.

Cara identifikasi:

  • Buka Chrome DevTools → tab Performance
  • Rekam interaksi (klik tombol, isi form)
  • Cari blok merah berlabel "Long Task"
  • Lihat script mana yang menyebabkannya

Solusi praktis:

  • Load script pihak ketiga dengan atribut defer atau async
  • Gunakan Google Tag Manager dengan firing trigger "DOM Ready" bukan "Page View" untuk script non-kritis
  • Audit script yang dipasang di GTM — hapus yang sudah tidak dipakai

Kesalahan Umum: Memasang 5–8 tracking pixel sekaligus (Facebook Pixel, TikTok Pixel, Google Ads, Hotjar, dll.) tanpa mempertimbangkan dampak ke INP. Setiap pixel tambahan bisa menambah 20–50ms ke INP.

Perbaikan CLS: Kenapa Halaman Anda "Loncat-loncat"

CLS tinggi biasanya disebabkan oleh:

  1. Iklan tanpa dimensi tetap — slot iklan yang ukurannya tidak didefinisikan sebelum konten iklan load
  2. Font web yang swap — teks bergeser saat web font menggantikan fallback font
  3. Gambar tanpa atribut width dan height — browser tidak bisa "reservasi" ruang sebelum gambar load
  4. Banner cookie atau pop-up yang muncul dan mendorong konten ke bawah

Checklist perbaikan CLS:

  • Tambahkan width dan height ke semua tag <img> (termasuk gambar di artikel lama)
  • Untuk slot iklan Google AdSense, definisikan min-height di CSS sesuai ukuran iklan
  • Gunakan font-display: optional atau font-display: swap dengan preload font
  • Posisikan banner cookie di bawah layar, bukan di atas konten
  • Hindari inject konten di atas fold setelah halaman selesai load

Tools Gratis untuk Monitoring CWV Berkelanjutan

Audit sekali tidak cukup. Perubahan tema, plugin baru, atau script tambahan bisa merusak skor CWV kapan saja. Berikut setup monitoring yang saya rekomendasikan:

Tool Fungsi Biaya
Google Search Console Field data per URL, laporan mingguan Gratis
PageSpeed Insights API Cek programatik per URL Gratis
Treo.sh Dashboard CrUX dengan tracking historis Gratis (basic)
WebPageTest Lab test dengan waterfall detail Gratis
Screaming Frog + PSI Audit CWV bulk untuk seluruh situs Berbayar (SF)

Setup monitoring mingguan:

  1. Buat laporan terjadwal di Google Search Console (kirim ke email)
  2. Gunakan Treo.sh — masukkan domain Anda, pantau tren LCP/INP/CLS per bulan
  3. Setiap kali update tema atau pasang plugin baru, langsung cek PageSpeed Insights untuk URL utama

Studi Kasus: Situs Otomotif dari "Buruk" ke "Baik" dalam 6 Minggu

Klien di niche review otomotif punya LCP mobile rata-rata 5,8 detik dan CLS 0,28. Traffic organik stagnan meski konten terus ditambah.

Yang kami lakukan (urutan prioritas):

  1. Minggu 1–2: Pindah hosting ke server Jakarta + aktifkan Cloudflare dengan cache HTML. TTFB turun dari 1,2 detik ke 380ms.
  2. Minggu 2–3: Konversi semua gambar ke WebP + tambah preload untuk gambar hero di template artikel. LCP turun dari 5,8 detik ke 3,1 detik.
  3. Minggu 3–4: Audit GTM — hapus 4 tag yang sudah tidak aktif, pindahkan semua tag ke trigger "DOM Ready". INP turun dari 380ms ke 190ms.
  4. Minggu 4–6: Tambah width/height ke semua gambar via bulk update database + fix slot iklan. CLS turun dari 0,28 ke 0,08.

Hasil setelah 6 minggu: Semua URL utama masuk kategori "Baik" di Search Console. Dalam 8 minggu berikutnya (setelah Google re-crawl dan update field data), traffic organik naik 34% dibanding periode yang sama tahun sebelumnya.

Catatan: Kenaikan traffic bukan semata karena CWV—konten juga dioptimasi paralel. Tapi halaman yang CWV-nya sudah hijau adalah yang pertama naik rankingnya.

Prioritas Pertama yang Harus Anda Kerjakan Sekarang

Kalau Anda hanya punya waktu satu jam minggu ini, lakukan ini:

Buka Google Search Console → Core Web Vitals → Mobile → filter "Buruk".

Lihat URL mana yang masuk grup "Buruk". Kalau ada pola (misalnya semua halaman kategori, atau semua halaman produk), itu artinya masalahnya ada di template—satu perbaikan bisa memperbaiki ratusan URL sekaligus.

Ambil satu URL perwakilan, jalankan di PageSpeed Insights, dan identifikasi apakah masalah utamanya LCP, INP, atau CLS. Dari situ, gunakan checklist di artikel ini untuk mulai perbaikan yang paling berdampak.

Jangan tunggu semua sempurna sebelum mulai. Perbaikan bertahap yang konsisten jauh lebih efektif daripada audit besar yang tidak pernah dieksekusi.