Cara Memperbaiki Core Web Vitals: LCP, INP & CLS

Core Web Vitals adalah tiga metrik yang dipakai Google untuk mengukur seberapa cepat, responsif, dan stabil halaman Anda terasa bagi pengguna nyata: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), dan Cumulative Layout Shift (CLS). Untuk lulus, Anda butuh skor "baik" pada ketiganya bagi 75% trafik Anda. Panduan ini menjelaskan arti setiap metrik dan langkah perbaikan yang benar-benar menggerakkannya.

Yang Akan Anda Pelajari

• Apa yang diukur LCP, INP, dan CLS, serta ambang batas "baik" untuk masing-masing
• Perbaikan spesifik yang meningkatkan setiap metrik, sesuai urutan prioritas
• Cara membedakan field data dan lab data, serta mengapa perbedaannya penting
• Seberapa besar Core Web Vitals benar-benar memengaruhi peringkat Google Anda
• Perbaikan mana yang bisa Anda tangani sebagai marketer, dan mana yang butuh developer

Apa yang Sebenarnya Diukur Core Web Vitals

Core Web Vitals menilai tiga hal: pemuatan (loading), responsivitas, dan stabilitas visual. Google mengukurnya dari pengguna Chrome nyata melalui Chrome User Experience Report (CrUX), lalu melaporkan persentil ke-75, artinya 75% kunjungan Anda harus mencapai batas "baik". Berikut ambang batasnya langsung dari dokumentasi web.dev milik Google.

Metrik	Yang diukur	Baik	Perlu perbaikan	Buruk
LCP	Pemuatan: kapan elemen terbesar muncul	2,5 dtk atau kurang	2,5-4,0 dtk	Di atas 4,0 dtk
INP	Responsivitas: jeda setelah interaksi	200 ms atau kurang	200-500 ms	Di atas 500 ms
CLS	Stabilitas visual: pergeseran tata letak	0,1 atau kurang	0,1-0,25	Di atas 0,25

Ambang batas: web.dev (Google), halaman definisi metrik. Satu catatan sejarah: INP menggantikan First Input Delay (FID) sebagai Core Web Vital pada 2024, jadi panduan lama yang masih menyebut FID sudah usang.

Field data vs. lab data

Ada dua jenis data yang mengukur metrik ini, dan hanya satu yang dihitung untuk peringkat. Field data berasal dari pengunjung nyata Anda dan mengisi CrUX, inilah yang dipakai Google. Lab data berasal dari satu pengujian simulasi di alat seperti Lighthouse. Lab data bagus untuk debugging, tetapi skor lab yang sempurna tidak akan meluluskan Anda jika pengguna nyata masih kesulitan.

Seberapa Besar Core Web Vitals Memengaruhi Peringkat?

Core Web Vitals adalah salah satu faktor peringkat, bukan faktor penentu. Google menegaskan bahwa sistem peringkatnya memakai Core Web Vitals, tetapi skor bagus tidak menjamin peringkat lebih tinggi, dan Search tetap menampilkan konten paling relevan sekalipun pengalaman halamannya buruk (Google Search Central). Perlakukan Core Web Vitals sebagai penentu di antara halaman yang setara dan sebagai kemenangan pengalaman pengguna yang nyata, bukan jalan pintas mengalahkan konten yang lebih baik.

Cara Memperbaiki LCP (Largest Contentful Paint)

LCP dianggap "baik" pada 2,5 detik atau kurang. Metrik ini mengukur kapan elemen terbesar yang terlihat, biasanya gambar hero, judul, atau blok teks besar, selesai dimuat. Google membagi LCP menjadi empat bagian: waktu respons server, jeda pemuatan sumber daya, durasi pemuatan sumber daya, dan jeda render (web.dev). Kerjakan secara berurutan.

1. Percepat respons server Anda. Gunakan hosting berkualitas, content delivery network (CDN), dan caching agar byte pertama halaman tiba dengan cepat. Server yang lambat menunda semua yang mengikutinya.
2. Buat elemen LCP mudah ditemukan. Browser tidak bisa memuat apa yang tidak terlihat lebih awal. Letakkan gambar hero langsung di dalam HTML, bukan dimuat lewat skrip, dan minta developer Anda menambahkan fetchpriority="high" atau petunjuk preload agar dimuat lebih dulu.
3. Perkecil sumber daya LCP. Kompres gambar Anda dan sajikan format modern seperti WebP atau AVIF. Sesuaikan ukuran setiap gambar dengan ruang yang diisinya, dan sajikan lewat CDN.
4. Pangkas kode yang menghambat render. File CSS dan JavaScript yang besar menunda tampilan pertama. Minifikasi file tersebut, tunda skrip non-kritis, dan hapus kode yang tidak Anda pakai.

Bagi sebagian besar situs marketing, masalah LCP biasanya berasal dari gambar yang berat atau hosting yang lambat, yang juga merupakan dua perbaikan termudah.

Cara Memperbaiki INP (Interaction to Next Paint)

INP dianggap "baik" pada 200 milidetik atau kurang. Metrik ini mengukur seberapa cepat halaman Anda merespons setelah pengguna mengetuk, mengeklik, atau mengetik, sepanjang seluruh kunjungan, bukan hanya interaksi pertama. INP yang lambat hampir selalu berarti JavaScript membebani main thread, satu-satunya jalur yang dipakai browser untuk merespons (web.dev).

1. Pecah tugas panjang. Tugas JavaScript yang panjang memblokir browser dari merespons. Bagi pekerjaan berat menjadi bagian-bagian kecil dan serahkan kembali ke main thread agar halaman bisa bereaksi di antaranya.
2. Kirim lebih sedikit JavaScript. Setiap skrip bersaing memperebutkan thread yang sama. Audit tag pihak ketiga Anda, karena widget chat, heatmap, dan skrip iklan sering menjadi biang keladi, lalu hapus yang tidak Anda butuhkan.
3. Jaga penangan interaksi tetap ringan. Saat seseorang mengeklik, tampilkan perubahan yang terlihat lebih dulu, baru tangani sisanya. Tunda analytics dan logika yang tidak mendesak agar tidak memperlambat respons.
4. Kurangi kompleksitas halaman. DOM yang sangat besar (terlalu banyak elemen di halaman) memperlambat setiap interaksi. Sederhanakan template dan gunakan content-visibility untuk melewati render bagian yang di luar layar.

INP adalah metrik yang paling sering gagal dilewati tim marketing, karena tag manager dan skrip pihak ketiga menumpuk seiring waktu. Audit tag sering kali menjadi perbaikan tunggal yang paling besar dampaknya.

Cara Memperbaiki CLS (Cumulative Layout Shift)

CLS dianggap "baik" pada 0,1 atau kurang. Metrik ini mengukur seberapa banyak konten Anda melompat-lompat saat halaman dimuat, pergeseran menjengkelkan yang membuat Anda salah menekan tombol. Sebagian besar CLS berasal dari elemen yang dimuat tanpa ruang yang sudah disediakan (web.dev).

1. Tetapkan dimensi pada gambar dan video. Selalu sertakan atribut width dan height (atau aspect-ratio di CSS) agar browser menyediakan ruang yang tepat sebelum file dimuat.
2. Sediakan ruang untuk iklan, embed, dan banner. Beri slot dinamis ukuran tetap. Hindari menyisipkan konten di atas yang sudah tampil di layar kecuali diminta pengguna, dan dorong konten yang dimuat belakangan ke posisi lebih bawah.
3. Perbaiki font Anda. Font web yang berganti terlambat bisa menggeser teks Anda. Gunakan font-display: optional atau font cadangan yang cocok, dan selaraskan ukurannya dengan size-adjust agar pergantiannya tidak terlihat.
4. Animasikan dengan cara yang benar. Animasikan dengan transform di CSS, bukan properti seperti top atau left yang memaksa tata letak bergeser.

CLS biasanya paling cepat diperbaiki, sering kali cukup dengan menambahkan dimensi gambar dan menyediakan ruang iklan.

Urutan Perbaikan Sederhana untuk Marketer

Mulailah dari titik yang paling terasa sakit. Ambil field data Anda lebih dulu, lalu perbaiki metrik yang gagal bagi paling banyak pengguna. Jika Anda memulai dari nol, urutan ini paling cepat membuahkan hasil bagi sebagian besar situs.

1. CLS cepat, murah, dan dampaknya terlihat jelas
2. LCP kompres gambar dan tingkatkan hosting
3. INP audit skrip dan tag pihak ketiga

Anda bisa menangani kompresi gambar, audit tag, dan keputusan konten sendiri. Libatkan developer untuk petunjuk preload, code splitting, dan penyetelan font. Brief yang jelas seperti "LCP kami 4,2 detik di mobile, sebagian besar dari gambar hero" mempercepat perbaikan dibanding sekadar "buat situsnya lebih cepat".

Cara Mengukur Kemajuan Anda

Ukurlah dengan field data, karena itulah yang dinilai Google. PageSpeed Insights gratis dari Google menampilkan field data CrUX sekaligus pengujian lab dalam satu laporan. Karena field data dikumpulkan dari pengguna nyata selama rentang bergulir beberapa minggu, perbaikan Anda tidak muncul seketika, jadi bersiaplah menunggu sebelum skornya diperbarui (web.dev, dokumentasi CrUX). Teruslah menerapkan perbaikan dan biarkan datanya menyusul.

Pertanyaan yang Sering Diajukan

Apakah Core Web Vitals faktor peringkat Google?

Ya, tetapi faktor kecil. Google menegaskan sistem peringkatnya memakai Core Web Vitals, namun skor bagus tidak menjamin peringkat lebih tinggi, dan konten relevan tetap muncul di peringkat sekalipun pengalaman halamannya buruk (Google Search Central). Perbaiki demi pengguna lebih dulu, dan anggap manfaat peringkat sebagai bonus.

Apa beda field data dan lab data?

Field data berasal dari pengunjung nyata dan mengisi laporan CrUX Google, inilah yang dihitung untuk peringkat. Lab data berasal dari satu pengujian simulasi seperti Lighthouse dan paling cocok untuk debugging. Sebuah halaman bisa lulus di lab tetapi tetap gagal di lapangan.

Berapa lama perbaikan Core Web Vitals saya terlihat hasilnya?

Skor lapangan diperbarui lewat rentang bergulir data pengguna nyata, jadi bersiaplah menunggu beberapa minggu, bukan beberapa hari, setelah Anda menerapkan perbaikan. Alat lab menampilkan perubahan seketika, yang membantu Anda memastikan perbaikan berhasil sembari menunggu field data bergerak.

Apakah saya butuh developer untuk memperbaiki Core Web Vitals?

Tidak selalu. Marketer bisa mengompres gambar, mengaudit tag pihak ketiga, dan menyediakan ruang untuk iklan sendiri. Perbaikan yang lebih dalam seperti code splitting, petunjuk preload, dan penyetelan font biasanya butuh developer. Brief yang spesifik mempercepat keduanya.

Core Web Vital mana yang harus saya perbaiki lebih dulu?

Perbaiki yang gagal bagi paling banyak pengguna nyata, yang bisa Anda lihat di field data. Jika belum ada data sebagai panduan, CLS biasanya paling cepat menang, disusul LCP (gambar dan hosting) dan INP (pembersihan skrip dan tag).

Kesimpulan

Core Web Vitals menghargai hal yang sama dengan keinginan pengunjung Anda: halaman yang cepat dimuat, langsung merespons, dan tidak bergeser. Capai LCP 2,5 detik atau kurang, INP 200 milidetik atau kurang, dan CLS 0,1 atau kurang bagi 75% trafik Anda, maka Anda telah membangun pengalaman yang benar-benar lebih baik dengan sedikit keuntungan peringkat sebagai tambahan. Mulai dari field data Anda, perbaiki kegagalan terbesar lebih dulu, lalu ukur lagi beberapa minggu kemudian.

Sumber (Tier 1)

• Web Vitals web.dev (Google): https://web.dev/articles/vitals
• Largest Contentful Paint (LCP) web.dev: https://web.dev/articles/lcp
• Interaction to Next Paint (INP) web.dev: https://web.dev/articles/inp
• Cumulative Layout Shift (CLS) web.dev: https://web.dev/articles/cls
• Optimize Largest Contentful Paint web.dev: https://web.dev/articles/optimize-lcp
• Optimize Interaction to Next Paint web.dev: https://web.dev/articles/optimize-inp
• Optimize Cumulative Layout Shift web.dev: https://web.dev/articles/optimize-cls
• Understanding page experience in Google Search Google Search Central: https://developers.google.com/search/docs/appearance/page-experience
• Overview of CrUX Chrome for Developers: https://developer.chrome.com/docs/crux