Core Web Vitals 2026: Panduan Praktis untuk Situs Bisnis

Tiga singkatan yang menentukan berapa orang meninggalkan situsmu

Agensi mengirim laporan. Isinya: "LCP 4,8 detik, INP 380 ms, CLS 0,26 — perlu optimasi." Kamu menyetujui anggarannya karena tidak enak bertanya, bukan karena paham apa yang dibeli.

Mari terjemahkan ketiganya ke bahasa yang bisa dipakai mengambil keputusan.

LCP (Largest Contentful Paint) — berapa lama sampai elemen terbesar di layar muncul. Biasanya foto hero atau judul halaman. Ini jawaban atas pertanyaan pengunjung: "halaman ini jalan atau tidak?" Batas baik: 2,5 detik.

INP (Interaction to Next Paint) — jeda antara pengunjung menekan sesuatu dan layar berubah. Tombol menu, dropdown, tombol kirim. Jawaban atas "tadi ke-klik tidak, ya?" Batas baik: 200 milidetik.

CLS (Cumulative Layout Shift) — seberapa banyak isi halaman melompat saat sedang dibaca. Kamu hendak menekan tombol, gambar selesai dimuat, tombolnya bergeser, kamu menekan iklan. Batas baik: 0,1.

Kenapa ini urusan bisnis, bukan urusan teknis:

• Ketiganya adalah faktor peringkat Google yang dikonfirmasi, di bawah relevansi konten tapi menjadi penentu ketika beberapa halaman sama-sama relevan.
• Data lapangan Google menunjukkan probabilitas pengunjung meninggalkan halaman naik tajam seiring bertambahnya waktu muat — dari 1 ke 3 detik, kenaikannya berlipat.
• Angkanya diambil dari pengunjung sungguhan selama 28 hari. Artinya perbaikan tidak terasa besok; perbaikan terasa dalam empat minggu. Semakin cepat dimulai, semakin cepat terhitung.

Panduan ini menerjemahkan setiap metrik ke tindakan yang bisa kamu berikan ke tim developer minggu ini — lengkap dengan cara memverifikasi bahwa pekerjaannya benar-benar dilakukan.

Membaca angkanya sendiri, tanpa perantara

Buka pagespeed.web.dev, masukkan alamat situs. Yang penting dibaca ada dua bagian, dan orang sering salah membaca yang mana.

Bagian atas — "Discover what your real users are experiencing". Ini data pengunjung asli (CrUX). Inilah yang dipakai Google. Kalau bagian ini tidak muncul, trafik situsmu belum cukup untuk masuk dataset — pakai bagian bawah sementara waktu.

Bagian bawah — "Diagnose performance issues". Ini simulasi Lighthouse pada satu perangkat. Berguna untuk mencari penyebab, tapi skor 0–100 di sini bukan yang dinilai Google. Jangan menetapkan KPI tim pada angka ini; ia berfluktuasi 10–15 poin antar-run pada situs yang sama.

Satu kebiasaan yang menghemat banyak perdebatan: selalu baca kolom mobile, bukan desktop. Mayoritas trafik situs bisnis Indonesia datang dari ponsel, dan Google memakai indeks mobile-first.

Cara membaca hasilnya:

Catat angka hari ini di spreadsheet, dengan tanggal. Empat minggu setelah perbaikan, buka lagi. Tanpa catatan itu, kamu akan menerima klaim "sudah lebih cepat" tanpa bisa memverifikasinya.

LCP lambat: hampir selalu tiga hal yang sama

Ketika LCP di atas 2,5 detik, penyebabnya nyaris selalu ada di daftar ini — urut dari yang paling sering.

1. Foto hero yang terlalu besar

Ini penyebab nomor satu, dan yang paling murah diperbaiki. Foto 3,4 MB langsung dari kamera atau dari stok foto, dipasang ke halaman depan tanpa diproses.

Cara memeriksanya sendiri, tanpa developer: klik kanan pada foto besar di halaman depan → "Open image in new tab" → lihat ukurannya di tab Network DevTools. Atau lebih cepat, dari terminal:

curl -sI https://situskamu.com/images/hero.jpg | grep -i content-length

content-length: 3412880

3,4 MB. Pada koneksi 4G Indonesia yang tipikal (sekitar 10 Mbps efektif), itu hampir 3 detik hanya untuk satu file.

Yang harus diminta ke tim:

• Format WebP atau AVIF, bukan JPG. Ukurannya sekitar 25–35% lebih kecil pada kualitas visual setara.
• Lebar maksimum 1600 px untuk hero, bukan 4000 px. Layar ponsel tidak akan pernah menampilkan detail sebanyak itu.
• Kualitas 80. Perbedaan dengan 100 tidak terlihat mata, ukurannya turun setengah.

Target realistis: di bawah 150 KB untuk gambar hero. Dari 3,4 MB ke 120 KB adalah perbaikan 28 kali lipat dari satu file, dan biasanya cukup untuk memindahkan LCP dari merah ke kuning sendirian.

2. Font yang menahan teks

Situs memakai font kustom. Sampai file font-nya selesai diunduh, browser menampilkan teks kosong — layar putih dengan gambar tapi tanpa tulisan. Ini juga terhitung sebagai LCP lambat kalau elemen terbesarnya adalah judul.

Yang diminta ke tim, tiga hal, semuanya satu baris:

• font-display: swap — teks langsung tampil dengan font cadangan, lalu ditukar.
• Host font di server sendiri, bukan dari Google Fonts. Menghemat satu koneksi DNS + TLS ke domain lain, sekitar 100–300 ms pada koneksi seluler.
• Muat maksimal dua ketebalan (misalnya regular dan bold). Setiap ketebalan tambahan adalah file terpisah.

3. Terlalu banyak skrip pihak ketiga

Setiap tag yang dipasang tim marketing punya harga. Yang khas pada situs bisnis Indonesia:

Total realistis: 500–800 KB skrip yang tidak satu pun merupakan konten yang dicari pengunjung.

Pertanyaan yang berhak kamu ajukan untuk setiap tag: kapan terakhir kali datanya dipakai untuk mengambil keputusan? Pixel yang dipasang untuk kampanye tahun lalu dan tidak pernah dicabut adalah biaya kecepatan yang dibayar setiap pengunjung, setiap hari.

Untuk yang memang harus tetap ada, minta dua hal: muat widget chat hanya setelah pengunjung menggulir atau setelah 5 detik, dan pastikan setiap tag memakai atribut async atau defer.

INP: tombol yang terasa "berat"

Gejalanya kamu sudah kenal. Menekan menu hamburger, tidak ada yang terjadi, kamu menekan lagi, lalu menu terbuka dua kali dan tertutup lagi.

Penyebab teknisnya: JavaScript hanya punya satu jalur kerja. Kalau ada tugas yang berjalan lama, semua interaksi antre di belakangnya. Pada situs bisnis, tiga sumber yang paling umum:

• Efek animasi saat menggulir yang menghitung ulang posisi puluhan elemen pada setiap piksel gerakan.
• Slider atau carousel dari plugin lama, terutama yang masih memakai jQuery dan menganimasi lewat JavaScript alih-alih CSS.
• Skrip pihak ketiga yang menjalankan pekerjaannya tepat saat halaman selesai dimuat — persis saat pengunjung mulai menekan sesuatu.

Cara memeriksa sendiri, dan ini tidak butuh alat apa pun: buka situs di ponsel sungguhan — bukan mode ponsel di browser desktop, yang tidak mensimulasikan kecepatan prosesornya. Pakai ponsel kelas menengah berumur dua–tiga tahun, matikan WiFi, gunakan data seluler. Tekan menu, tekan tombol CTA, buka dropdown. Kalau terasa nyangkut, INP kamu merah, apa pun kata laporannya.

Yang diminta ke tim: ganti animasi scroll berbasis JavaScript dengan IntersectionObserver, ganti animasi jQuery dengan transisi CSS, dan tunda semua skrip pihak ketiga sampai setelah interaksi pertama.

CLS: halaman yang melompat

Ini yang paling mengganggu pengunjung dan paling mudah diperbaiki — biasanya kurang dari sehari kerja.

Empat sumber, dan cara memverifikasi masing-masing sudah diperbaiki:

Gambar tanpa ukuran. Browser tidak tahu ruang yang harus dipesan, jadi teks di bawahnya melompat begitu gambar datang. Perbaikannya adalah atribut width dan height pada setiap gambar. Verifikasi: klik kanan pada gambar → Inspect. Kalau tidak ada width="..." dan height="..." di tag <img>, belum diperbaiki.

Banner atau notifikasi yang muncul di atas konten. Bar "Diskon 20%" yang muncul dua detik setelah halaman terbuka mendorong seluruh halaman ke bawah. Perbaikannya: sediakan ruangnya sejak awal, atau tampilkan sebagai lapisan mengambang yang tidak mendorong apa pun.

Iklan dan embed. Slot iklan yang tingginya berubah-ubah, embed Instagram atau YouTube tanpa ukuran tetap. Perbaikannya: tinggi minimum tetap untuk setiap slot.

Font yang menukar diri. Font cadangan dan font asli punya lebar huruf berbeda, jadi paragraf menata ulang dirinya. Perbaikannya bersifat teknis (size-adjust pada font cadangan), tapi dampaknya nyata pada halaman yang panjang.

Cara memeriksa dengan mata: buka halaman, dan jangan sentuh apa pun selama lima detik pertama. Perhatikan apakah ada yang bergeser. Kalau kamu merasa perlu menunggu sebelum menekan sesuatu, pengunjungmu juga merasakan hal yang sama.

Memantau tanpa menunggu laporan bulanan

Data CrUX bergerak lambat karena rata-rata 28 hari. Untuk melihat efek perbaikan lebih cepat, minta tim memasang pengukuran dari pengunjung sendiri. Ini kode kecil, bukan proyek:

<script type="module">
  import { onLCP, onINP, onCLS } from 'https://unpkg.com/web-vitals@4?module';
  const kirim = (m) => navigator.sendBeacon('/services/vitals', JSON.stringify({
    metrik: m.name, nilai: Math.round(m.value), halaman: location.pathname,
  }));
  onLCP(kirim); onINP(kirim); onCLS(kirim);
</script>

Endpoint-nya menyimpan ke tabel yang sudah ada. Dengan itu, kamu bisa bertanya hal yang tidak bisa dijawab PageSpeed Insights:

• Halaman mana yang paling lambat? (Sering kali bukan homepage, tapi halaman kategori atau detail produk.)
• Apakah kecepatannya berbeda antara pengunjung Jakarta dan luar Jawa?
• Apakah deploy Selasa kemarin memperburuk sesuatu? — pertanyaan yang tanpa data ini baru terjawab empat minggu kemudian.

Kalau tim menolak dengan alasan "menambah skrip malah memperlambat": pustaka web-vitals berukuran sekitar 2 KB terkompresi dan berjalan setelah halaman selesai dimuat. Biayanya nyata tapi sangat kecil dibanding satu widget chat.

Daftar permintaan yang bisa kamu kirim minggu ini

Salin ini ke tim developer atau agensi. Semuanya spesifik dan bisa diverifikasi:

1. Kompres semua gambar di homepage dan halaman landing ke WebP, lebar maks 1600 px, di bawah 150 KB per gambar. Verifikasi: curl -sI <url-gambar> | grep -i content-length.
2. Tambahkan atribut width dan height pada setiap tag <img>. Verifikasi: Inspect elemen, atribut harus terlihat.
3. Pasang font-display: swap dan host font di server sendiri, maksimal dua ketebalan.
4. Audit semua skrip pihak ketiga. Cabut yang datanya tidak dipakai enam bulan terakhir. Tunda widget chat sampai 5 detik atau sampai pengunjung menggulir.
5. Beri tinggi minimum tetap untuk setiap slot banner, iklan, dan embed.
6. Pasang web-vitals dengan endpoint sendiri, dan tampilkan angkanya di panel admin.
7. Kirim tangkapan layar PageSpeed Insights mobile sebelum dan empat minggu sesudah, bagian atas (data pengunjung asli), bukan skor Lighthouse.

Butir 1 dan 2 saja biasanya memindahkan dua dari tiga metrik ke hijau, dan keduanya pekerjaan setengah hari. Mulai dari sana sebelum menyetujui paket optimasi apa pun yang lebih besar.