Core Web Vitals (LCP, INP, CLS): Panduan Praktis Memperbaiki Kecepatan Website Bisnis

Banyak pemilik bisnis pernah mendengar bahwa website harus cepat, tetapi sulit menerjemahkan nasihat itu menjadi pekerjaan konkret. Cepat menurut siapa? Diukur dengan apa? Di perangkat yang mana? Core Web Vitals adalah jawaban Google atas pertanyaan tersebut: tiga metrik yang mengukur seberapa cepat konten utama muncul, seberapa responsif halaman terhadap sentuhan, dan seberapa stabil tata letaknya selama dimuat.

Artikel ini menjelaskan ketiga metrik itu dengan bahasa yang bisa dipakai pemilik bisnis dan tim pemasaran, bukan hanya pengembang. Anda akan melihat apa arti angkanya, di mana mengecek skor website sendiri, penyebab paling umum nilai yang buruk, dan urutan perbaikan yang memberi hasil terbesar. Pembahasan umum tentang dampak kecepatan terhadap penjualan ada di artikel kecepatan website dan dampaknya; di sini fokusnya adalah metrik spesifik yang dipakai mesin pencari.

Ringkasan

• Core Web Vitals terdiri dari tiga metrik: LCP (kecepatan konten utama), INP (responsivitas terhadap interaksi), dan CLS (stabilitas tata letak)
• Nilai dinilai baik jika LCP 2,5 detik atau kurang, INP 200 milidetik atau kurang, dan CLS 0,1 atau kurang, diukur pada persentil ke-75 kunjungan nyata
• Data yang paling penting berasal dari pengguna sungguhan di ponsel, bukan hanya hasil uji laboratorium di laptop pengembang
• Sebagian besar masalah berasal dari gambar terlalu besar, skrip pihak ketiga yang berat, font yang memblokir tampilan, dan elemen tanpa ukuran tetap
• Perbaikan terbaik dilakukan berurutan: ukur, temukan halaman terburuk, perbaiki penyebab terbesar, lalu pantau agar tidak memburuk lagi

Apa itu Core Web Vitals dan mengapa bisnis perlu peduli?

Core Web Vitals adalah sekumpulan metrik pengalaman pengguna yang diumumkan Google dan dimasukkan sebagai salah satu sinyal dalam penilaian halaman. Perlu dipahami proporsinya dengan jujur: relevansi konten tetap jauh lebih penting daripada skor kecepatan. Halaman yang lambat tetapi menjawab pertanyaan pencari dengan sangat baik masih bisa berperingkat tinggi. Namun ketika dua halaman sama-sama relevan, pengalaman yang lebih baik cenderung menang, dan yang lebih penting lagi, pengalaman yang buruk membuat pengunjung pergi sebelum sempat menjadi prospek.

Karena itu, alasan paling kuat untuk memperbaiki Core Web Vitals bukan sekadar peringkat, melainkan konversi. Pengunjung dari iklan atau pencarian yang menunggu tiga detik untuk melihat halaman, lalu menekan tombol yang tidak merespons, jarang kembali. Setiap perbaikan pada metrik ini hampir selalu terasa langsung oleh pengunjung nyata, sehingga manfaatnya dapat dihitung pada formulir yang terkirim dan pesan WhatsApp yang masuk.

Tiga metrik yang perlu dipahami

LCP: seberapa cepat konten utama terlihat

Largest Contentful Paint mengukur waktu sampai elemen terbesar di layar awal selesai tampil, biasanya foto utama, gambar banner, atau blok judul besar. Nilai yang baik adalah 2,5 detik atau kurang; di atas 4 detik dianggap buruk. Bagi pengunjung, ini adalah momen ketika halaman terasa sudah terbuka. Pada website bisnis, elemen LCP hampir selalu gambar hero, sehingga cara gambar itu dikirim menentukan hampir seluruh skor.

INP: seberapa cepat halaman merespons

Interaction to Next Paint menggantikan metrik lama bernama First Input Delay pada Maret 2024. Berbeda dengan pendahulunya yang hanya mengukur interaksi pertama, INP memperhatikan semua interaksi selama kunjungan, yaitu klik, ketukan, dan penekanan tombol, lalu melaporkan yang terburuk atau mendekati terburuk. Nilai yang baik adalah 200 milidetik atau kurang; di atas 500 milidetik dianggap buruk. Masalahnya muncul ketika browser sedang sibuk menjalankan JavaScript sehingga tidak sempat menampilkan respons terhadap ketukan pengguna. Menu yang lambat terbuka atau tombol keranjang yang seolah mati adalah gejala klasiknya.

CLS: seberapa stabil tata letak

Cumulative Layout Shift mengukur seberapa banyak elemen bergeser secara tidak terduga selama halaman dimuat. Angkanya tanpa satuan, dan nilai yang baik adalah 0,1 atau kurang. Semua orang pernah mengalaminya: akan menekan satu tombol, lalu iklan atau gambar muncul di atasnya dan tombol terdorong ke bawah sehingga yang tertekan justru tautan lain. Pada halaman produk atau formulir, pergeseran seperti ini langsung menurunkan kepercayaan dan menimbulkan salah klik.

Cara mengecek skor website Anda

Ada dua jenis data yang perlu dibedakan. Data lapangan berasal dari pengguna nyata dan itulah yang dipakai untuk penilaian. Data laboratorium berasal dari simulasi terkontrol yang berguna untuk menemukan penyebab dan menguji perbaikan, tetapi bukan angka resmi.

• Laporan Core Web Vitals di Google Search Console mengelompokkan halaman Anda menjadi baik, perlu perbaikan, dan buruk berdasarkan data lapangan, terpisah untuk ponsel dan desktop
• PageSpeed Insights menampilkan data lapangan jika trafik cukup, ditambah diagnosis laboratorium dengan daftar peluang perbaikan
• Lighthouse di browser Chrome cocok untuk menguji perubahan sebelum dirilis
• Data dari pemantauan pengguna nyata di website Anda sendiri berguna untuk melihat tren per halaman, per perangkat, dan per negara

Mulailah dari Search Console karena laporannya mengelompokkan halaman sejenis, misalnya semua halaman produk atau semua artikel blog. Satu perbaikan pada templat biasanya memperbaiki ratusan halaman sekaligus. Jika website baru atau trafiknya rendah, data lapangan mungkin belum tersedia; dalam kasus itu gunakan uji laboratorium pada perangkat ponsel dengan jaringan yang dibatasi sebagai pendekatan.

Penyebab umum nilai buruk dan cara memperbaikinya

Memperbaiki LCP

• Kompres dan ubah gambar hero ke format modern seperti WebP atau AVIF, dengan ukuran sesuai kebutuhan layar, bukan foto kamera berukuran belasan megabita
• Sediakan beberapa ukuran gambar agar ponsel tidak mengunduh versi desktop
• Jangan menunda pemuatan gambar utama; gambar di bagian atas halaman harus dimuat segera, sedangkan gambar di bawah layar boleh ditunda
• Kurangi waktu respons server dengan caching, jaringan pengiriman konten, dan kueri database yang efisien, sebagaimana dibahas di [performa database dan aplikasi bisnis](/blog/performa-database-dan-aplikasi-bisnis-yang-melambat)
• Hindari slider besar di bagian atas yang memuat banyak gambar sekaligus

Memperbaiki INP

• Audit skrip pihak ketiga seperti widget obrolan, pelacak iklan, peta, dan pemutar video; setiap skrip menambah pekerjaan bagi browser
• Tunda pemuatan skrip yang tidak dibutuhkan di layar awal sampai pengguna berinteraksi atau halaman selesai dimuat
• Pecah tugas JavaScript yang panjang menjadi bagian kecil agar browser sempat merespons
• Batasi penggunaan pustaka besar untuk fungsi kecil; sering kali beberapa baris kode biasa cukup
• Pada aplikasi yang banyak memakai kerangka kerja JavaScript, pertimbangkan penyajian di sisi server agar lebih sedikit kode berjalan di perangkat pengguna

Memperbaiki CLS

• Tentukan lebar dan tinggi (atau rasio aspek) pada semua gambar dan video sehingga browser menyisihkan ruangnya sebelum file selesai diunduh
• Sediakan ruang tetap untuk iklan, banner persetujuan cookie, dan widget yang muncul belakangan
• Pilih font dengan strategi pemuatan yang tidak membuat teks melompat; gunakan font cadangan yang ukurannya mirip
• Jangan menyisipkan konten baru di atas konten yang sudah tampil, kecuali sebagai respons atas tindakan pengguna
• Animasi sebaiknya memakai transformasi, bukan mengubah ukuran atau posisi elemen yang memengaruhi tata letak

Skrip pihak ketiga: penyebab yang paling sering diabaikan

Di banyak website bisnis, kode buatan tim sendiri justru ringan. Yang membebani adalah tambahan yang dipasang satu per satu oleh pemasaran dan penjualan: pelacak iklan dari beberapa platform, rekaman sesi, survei pop-up, widget obrolan, peta interaktif, dan alat pengujian A/B. Masing-masing memuat kodenya sendiri, sering dari server lain, dan tidak jarang saling menimpa.

Lakukan inventarisasi: daftar semua skrip pihak ketiga, tujuannya, siapa pemiliknya, dan apakah masih dipakai. Skrip untuk kampanye yang sudah berakhir dua tahun lalu adalah kandidat pertama untuk dihapus. Untuk yang tetap dibutuhkan, tanyakan apakah bisa dimuat setelah interaksi pertama, atau diganti dengan versi yang lebih ringan. Pengelolaan tag yang rapi juga bagus untuk pengukuran; panduan lebih lanjut ada di artikel tentang analitik website dan aplikasi mobile.

Urutan kerja yang disarankan

1. 01Buka laporan Core Web Vitals di Search Console dan catat kelompok halaman yang berstatus buruk atau perlu perbaikan, mulai dari ponsel
2. 02Pilih satu halaman wakil dari setiap kelompok, misalnya beranda, satu halaman layanan, satu artikel, dan satu halaman produk
3. 03Jalankan PageSpeed Insights pada halaman tersebut dan catat elemen LCP, skrip terberat, dan sumber pergeseran tata letak
4. 04Perbaiki penyebab terbesar lebih dulu, biasanya gambar hero dan skrip pihak ketiga
5. 05Uji ulang di laboratorium, rilis, lalu tunggu data lapangan diperbarui yang membutuhkan sekitar empat minggu penuh
6. 06Pasang pemantauan dan batas anggaran performa agar perubahan berikutnya tidak diam-diam menurunkan skor

Langkah terakhir sering dilewatkan, padahal paling menentukan dalam jangka panjang. Website yang cepat saat diluncurkan bisa menjadi lambat dalam setahun karena konten baru, plugin baru, dan skrip baru. Menetapkan batas, misalnya ukuran halaman maksimum atau jumlah skrip pihak ketiga, dan memeriksanya secara otomatis pada setiap rilis, jauh lebih murah daripada proyek perbaikan besar berkala. Pendekatan ini mirip dengan pemantauan uptime dan kesehatan website.

Peran CMS, tema, dan arsitektur website

Ada batas seberapa jauh optimasi bisa dilakukan jika fondasinya berat. Website berbasis tema siap pakai dengan puluhan plugin biasanya membawa banyak kode yang tidak terpakai pada setiap halaman. Pada kasus seperti ini, perbaikan kecil membantu, tetapi hasil terbaik datang dari menyederhanakan tema dan plugin, atau pada tahap tertentu, membangun ulang dengan arsitektur yang lebih ramping. Pilihan platform dibahas di CMS dan manajemen konten serta arsitektur website headless.

Jika Anda memutuskan membangun ulang, lindungi peringkat yang sudah ada dengan memperhatikan pengalihan, struktur URL, dan metadata, seperti dijelaskan di redesain dan migrasi website tanpa kehilangan peringkat SEO. Dasar-dasar optimasi lain yang saling melengkapi tercantum di SEO dasar website perusahaan.

Kesalahan yang sering terjadi

• Mengejar skor 100 di laboratorium padahal data lapangan sudah baik; skor sempurna tidak diperlukan dan biayanya tinggi
• Menguji hanya di desktop, padahal sebagian besar penilaian berdasarkan ponsel
• Memperbaiki satu halaman secara manual padahal masalahnya ada pada templat yang dipakai ratusan halaman
• Memasang plugin optimasi tanpa memahami apa yang diubahnya, sehingga fitur lain rusak
• Mengabaikan pengaruh banner cookie, widget obrolan, dan iklan terhadap CLS dan INP
• Tidak memantau setelah perbaikan, sehingga skor kembali turun setelah beberapa bulan

Pertanyaan yang sering diajukan

Apakah Core Web Vitals menentukan peringkat? Metrik ini adalah salah satu sinyal pengalaman halaman, tetapi bukan faktor tunggal dan bobotnya lebih kecil daripada relevansi konten. Perlakukan sebagai syarat pengalaman yang baik, bukan jalan pintas untuk naik peringkat.

Mengapa skor di PageSpeed Insights berbeda-beda setiap kali diuji? Uji laboratorium dipengaruhi kondisi jaringan dan beban perangkat saat itu. Gunakan tren dari beberapa kali pengujian dan utamakan data lapangan, yang lebih stabil karena merupakan agregat 28 hari.

Berapa lama perbaikan terlihat di Search Console? Karena data dikumpulkan selama 28 hari berjalan, perubahan biasanya baru tercermin sepenuhnya setelah sekitar satu bulan. Perbaikan nyata di pengguna sudah terasa sejak rilis.

Apakah website kecil dengan trafik sedikit perlu khawatir? Tetap perlu memastikan pengalaman dasar baik, tetapi tidak perlu proyek besar. Kompres gambar, kurangi plugin, dan hapus skrip yang tidak dipakai sudah menyelesaikan sebagian besar masalah.

Apakah perbaikan ini juga berguna untuk pengunjung internasional? Sangat berguna. Pengunjung dari wilayah dengan jaringan lebih lambat paling terdampak oleh halaman berat. Menggunakan jaringan pengiriman konten dan gambar yang ringan membantu semua pasar, termasuk untuk website multibahasa.

Kesimpulan

Core Web Vitals bukan teka-teki teknis yang hanya bisa dipahami pengembang. Tiga pertanyaannya sederhana: seberapa cepat konten utama muncul, seberapa cepat halaman merespons, dan seberapa stabil tampilannya. Dengan mengukur data pengguna nyata, memperbaiki penyebab terbesar lebih dulu, dan memantau secara berkelanjutan, website bisnis dapat memberi pengalaman yang lebih baik, peluang SEO yang lebih sehat, dan konversi yang lebih tinggi dari trafik yang sama.