Core Web Vitals 2025: Panduan Teknis untuk Situs Indonesia

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

Kebanyakan Situs Indonesia Gagal di Metrik yang Satu Ini

Setelah audit lebih dari 60 situs klien sepanjang 2024, saya menemukan pola yang konsisten: hampir 80% situs Indonesia gagal di INP (Interaction to Next Paint) — metrik yang menggantikan FID sejak Maret 2024. Bukan LCP, bukan CLS. INP.

Kenapa? Karena sebagian besar developer dan pemilik bisnis belum tahu INP itu ada. Mereka masih fokus memperbaiki LCP dan CLS, sementara INP skor merah terus menekan performa halaman di mata Google.

Core Web Vitals bukan sekadar checklist teknis. Ini sinyal ranking langsung. Google mengonfirmasi bahwa situs dengan Page Experience buruk akan kalah bersaing di SERP, bahkan ketika kontennya lebih relevan. Untuk pasar Indonesia — di mana mayoritas pengguna mengakses via mobile dengan jaringan 4G yang tidak stabil — dampaknya lebih besar lagi.

Artikel ini akan memandu Anda mengaudit dan memperbaiki ketiga metrik Core Web Vitals dengan pendekatan teknis yang bisa langsung dieksekusi minggu ini.


Kenapa Core Web Vitals Krusial untuk Pasar Indonesia

Data dari Chrome User Experience Report (CrUX) untuk domain .id menunjukkan bahwa median LCP situs e-commerce Indonesia ada di angka 4,2 detik — jauh di atas ambang batas "Good" Google yang 2,5 detik. Ini bukan masalah konten. Ini masalah infrastruktur dan optimasi teknis.

Tiga alasan Core Web Vitals lebih penting untuk bisnis Indonesia:

1. Pengguna mobile mendominasi. Lebih dari 75% traffic organik di klien kami datang dari mobile. Metrik Core Web Vitals diukur berdasarkan kondisi nyata pengguna — artinya skor Anda di lapangan (field data) bisa jauh lebih buruk dari hasil lab di PageSpeed Insights.

2. Koneksi tidak stabil = LCP meledak. Server yang bagus pun bisa menghasilkan LCP buruk kalau gambar hero tidak dioptimasi atau render-blocking resource tidak dibersihkan.

3. Google menggunakan field data, bukan lab data. Banyak yang tertipu skor PageSpeed Insights hijau, padahal CrUX data mereka merah. Yang masuk ke algoritma ranking adalah field data dari pengguna nyata.


Memahami Tiga Metrik Core Web Vitals 2025

Sebelum masuk ke checklist, pastikan Anda paham target angka yang harus dicapai:

Metrik Good Needs Improvement Poor
LCP (Largest Contentful Paint) ≤ 2,5 detik 2,5–4,0 detik > 4,0 detik
INP (Interaction to Next Paint) ≤ 200 ms 200–500 ms > 500 ms
CLS (Cumulative Layout Shift) ≤ 0,1 0,1–0,25 > 0,25

Google mengategorikan halaman sebagai "Good" hanya jika 75% pengguna nyata mengalami skor di zona hijau. Artinya, memperbaiki satu halaman saja tidak cukup — Anda perlu konsistensi di seluruh situs.


Checklist Audit dan Perbaikan Core Web Vitals

Gunakan urutan ini. Jangan loncat ke langkah 3 sebelum langkah 1 selesai — setiap perbaikan bisa memengaruhi metrik lain.

Langkah 1: Audit Field Data Dulu, Bukan Lab Data

  • Buka Google Search Console → Core Web Vitals report. Ini adalah field data nyata dari pengguna Anda.
  • Identifikasi URL dengan status "Poor" — prioritaskan halaman dengan traffic tertinggi.
  • Buka PageSpeed Insights (pagespeed.web.dev) untuk URL spesifik. Scroll ke bagian "Discover what your real users are experiencing" — ini field data CrUX.
  • Catat skor LCP, INP, dan CLS untuk mobile dan desktop secara terpisah.
  • Jika situs Anda belum punya cukup traffic untuk data CrUX, gunakan Lighthouse di Chrome DevTools (mode mobile, throttling 4G) sebagai proxy.

Kesalahan umum: Mengoptimasi berdasarkan skor lab PageSpeed Insights saja. Lab data menggunakan kondisi ideal — bukan kondisi pengguna Indonesia di lapangan.

Langkah 2: Perbaiki LCP (Target: ≤ 2,5 Detik)

LCP biasanya adalah gambar hero, foto produk utama, atau blok teks besar di above-the-fold.

  • Identifikasi elemen LCP: buka Chrome DevTools → Performance → rekam loading halaman → lihat elemen yang ditandai "LCP".
  • Preload LCP image: Tambahkan <link rel="preload" as="image" href="hero.webp"> di <head>. Ini satu perubahan yang bisa memangkas LCP 0,5–1 detik.
  • Konversi gambar ke WebP atau AVIF. Di WordPress, gunakan plugin Imagify atau ShortPixel. Di platform custom, gunakan sharp (Node.js) atau Pillow (Python) di pipeline build.
  • Aktifkan server-side caching dan CDN. Untuk situs Indonesia, CDN dengan PoP di Jakarta atau Singapura (Cloudflare, BunnyCDN, atau KeyCDN) bisa memangkas TTFB secara signifikan.
  • Hapus render-blocking CSS/JS. Di PageSpeed Insights, lihat bagian "Eliminate render-blocking resources". Defer JavaScript yang tidak dibutuhkan untuk rendering awal.
  • Gunakan fetchpriority="high" pada tag <img> elemen LCP. Ini memberi sinyal ke browser untuk memprioritaskan download gambar tersebut.

Tools: PageSpeed Insights, Chrome DevTools Performance tab, WebPageTest.org (pilih lokasi Jakarta).

Langkah 3: Perbaiki INP (Target: ≤ 200 ms)

INP mengukur responsivitas halaman terhadap interaksi pengguna — klik, tap, ketikan. Ini yang paling sering diabaikan.

  • Identifikasi interaksi lambat: Buka Chrome DevTools → Performance → rekam sesi interaksi (klik tombol, buka menu, isi form). Cari "Long Tasks" yang melebihi 50 ms.
  • Audit JavaScript pihak ketiga. Script iklan, live chat, pixel tracking — semuanya berkontribusi ke INP. Gunakan Request Map (requestmap.webperf.tools) untuk melihat semua third-party script yang dimuat.
  • Defer atau lazy-load script yang tidak kritis. Tambahkan atribut defer atau async pada script yang tidak perlu dijalankan saat halaman pertama dimuat.
  • Pecah Long Tasks. Jika Anda punya JavaScript custom yang berat, gunakan setTimeout atau scheduler.postTask() untuk memecah eksekusi menjadi chunk lebih kecil.
  • Kurangi DOM size. Halaman dengan lebih dari 1.500 node DOM akan lambat merespons interaksi. Audit dengan PageSpeed Insights → "Avoid an excessive DOM size".
  • Uji dengan LoAF (Long Animation Frames) API di Chrome 123+. Ini pengganti Long Tasks API yang lebih akurat untuk mendiagnosis INP.

Kesalahan umum: Menginstal plugin live chat atau popup tanpa mengukur dampaknya ke INP. Satu script yang salah konfigurasi bisa menaikkan INP dari 150 ms ke 600 ms.

Langkah 4: Perbaiki CLS (Target: ≤ 0,1)

CLS terjadi ketika elemen halaman bergeser saat loading — iklan yang muncul tiba-tiba, font yang baru dimuat, gambar tanpa dimensi.

  • Selalu tentukan width dan height pada tag <img>. Ini mencegah browser mengubah layout saat gambar selesai dimuat.
  • Reserve space untuk iklan dan embed. Jika Anda menggunakan Google AdSense atau slot iklan, tentukan ukuran container secara eksplisit di CSS.
  • Gunakan font-display: swap dengan hati-hati. swap bisa menyebabkan FOUT (Flash of Unstyled Text) yang menambah CLS. Pertimbangkan font-display: optional untuk font dekoratif.
  • Preload web fonts kritis. Tambahkan <link rel="preload" as="font"> untuk font yang digunakan di above-the-fold.
  • Audit dengan Chrome DevTools: Buka Rendering → Layout Shift Regions untuk melihat elemen mana yang bergeser.

Tools yang Saya Gunakan untuk Audit Core Web Vitals Klien

Berikut stack audit yang saya pakai — semuanya gratis atau freemium:

Untuk field data:

  • Google Search Console (Core Web Vitals report)
  • CrUX Dashboard (lookerstudio.google.com — cari template CrUX)
  • PageSpeed Insights (field data section)

Untuk lab data dan debugging:

  • Chrome DevTools (Performance tab + Rendering panel)
  • WebPageTest.org — pilih lokasi "Jakarta, Indonesia" untuk hasil yang representatif
  • Lighthouse CI — untuk monitoring otomatis di pipeline CI/CD

Untuk monitoring berkelanjutan:

  • SpeedVitals (speedvitals.com) — monitoring Core Web Vitals harian, ada alert jika skor turun
  • Treo Site Speed — visualisasi CrUX data historis

Untuk WordPress:

  • WP Rocket (caching + defer JS + lazy load)
  • Imagify atau ShortPixel (kompresi dan konversi WebP otomatis)
  • Perfmatters (disable script per halaman)

Contoh Nyata: Situs E-Commerce Fashion, Dari Poor ke Good dalam 3 Minggu

Klien saya — toko fashion online berbasis di Surabaya — datang dengan skor INP 780 ms dan LCP 5,8 detik di mobile. Traffic organiknya stagnan selama 4 bulan meski konten blog rutin diupdate.

Yang kami lakukan:

  1. Minggu 1: Preload gambar hero + konversi semua gambar produk ke WebP → LCP turun ke 3,1 detik.
  2. Minggu 2: Identifikasi dan defer 4 third-party script (live chat, dua pixel tracking, satu script A/B testing yang tidak aktif) → INP turun ke 310 ms.
  3. Minggu 3: Tambahkan dimensi eksplisit pada semua <img> + reserve space untuk banner promosi → CLS turun dari 0,28 ke 0,07.

Hasil setelah 6 minggu (termasuk lag indexing): traffic organik naik 34%, posisi rata-rata untuk 15 keyword utama naik 2,3 posisi.

Bukan sihir — ini perbaikan teknis yang terukur.


Satu Prioritas Pertama yang Harus Anda Kerjakan Hari Ini

Buka Google Search Console sekarang. Pergi ke Pengalaman → Core Web Vitals. Lihat berapa URL yang berstatus "Poor" di mobile.

Jika lebih dari 10 URL, mulai dari yang paling banyak traffic. Buka URL tersebut di PageSpeed Insights, identifikasi metrik mana yang merah, lalu eksekusi checklist di atas sesuai urutannya.

Jangan audit semua halaman sekaligus. Pilih satu URL, perbaiki sampai tuntas, ukur hasilnya di field data (butuh 28 hari untuk CrUX terupdate), baru lanjut ke URL berikutnya.

Core Web Vitals bukan proyek sekali jalan — ini monitoring berkelanjutan. Tapi perbaikan pertama yang konsisten adalah yang paling berdampak pada ranking Anda.