Core Web Vitals: Penjelasan LCP, INP, dan CLS (dan Cara Memperbaikinya)

Core Web Vitals adalah tiga metrik yang digunakan Google untuk mengukur pengalaman nyata di sebuah halaman: seberapa cepat halaman dimuat, seberapa cepat merespons, dan seberapa stabil selama dimuat. Metrik ini termasuk sinyal pengalaman halaman yang dipertimbangkan Google dalam peringkat, dan – yang lebih penting – mencerminkan bagaimana pengunjung benar-benar merasakan situs Anda.

Tiga Core Web Vitals

Halaman lolos jika setidaknya 75% kunjungan nyata (persentil ke-75) memenuhi ambang batas “baik” untuk ketiga metrik.

INP menggantikan First Input Delay (FID) sebagai Core Web Vital pada Maret 2024. INP lebih ketat: mempertimbangkan responsivitas interaksi sepanjang kunjungan, bukan hanya yang pertama.

Data lapangan vs data lab

Data lapangan berasal dari pengguna Chrome nyata dan dikumpulkan dalam Chrome UX Report (CrUX) selama periode bergulir 28 hari. Inilah yang dipakai Google untuk pengalaman halaman. Anda dapat melihatnya di laporan Core Web Vitals di Search Console dan di PageSpeed Insights.

Data lab berasal dari pengujian simulasi, seperti Lighthouse, pada perangkat dan jaringan yang tetap. Sangat bagus untuk debugging dan menguji perubahan, tetapi bukan yang dipakai Google untuk peringkat – dan tidak dapat mengukur INP secara langsung (Total Blocking Time adalah pendekatan lab yang paling dekat).

Halaman bertrafik rendah mungkin tidak memiliki cukup data lapangan; dalam hal ini Google dapat memakai data dari halaman serupa atau seluruh situs (“origin”).

Largest Contentful Paint (LCP)

LCP menandai waktu ketika gambar atau blok teks terbesar di viewport selesai dirender – biasanya gambar hero, judul besar, atau poster video unggulan.

LCP dapat dipecah menjadi empat bagian yang menunjuk pada perbaikannya:

1. Time to First Byte – berapa lama server merespons
2. Jeda pemuatan sumber daya – berapa lama sebelum browser mulai mengunduh sumber daya LCP
3. Waktu pemuatan sumber daya – berapa lama unduhan berlangsung
4. Jeda render elemen – waktu antara unduhan dan render

Cara memperbaiki LCP

• Percepat server: cache halaman, CDN, hosting lebih cepat, dan lebih sedikit kueri database
• Buat gambar LCP cepat ditemukan: gunakan <img> biasa di HTML (bukan latar CSS atau gambar yang disisipkan JavaScript) dan tambahkan fetchpriority="high"
• Jangan pernah menerapkan lazy loading pada gambar LCP
• Optimalkan gambar: dimensi yang tepat, WebP atau AVIF, kompresi yang baik
• Kurangi sumber daya yang memblokir render: sisipkan CSS kritis secara inline, tunda JavaScript yang tidak kritis
• Gunakan preconnect ke origin pihak ketiga yang diperlukan seperti CDN gambar

Interaction to Next Paint (INP)

INP mengukur jeda antara interaksi pengguna – klik, ketukan, atau tekan tombol – dan pembaruan visual berikutnya di layar. INP melaporkan salah satu interaksi paling lambat selama kunjungan.

INP yang buruk biasanya berasal dari terlalu banyak JavaScript yang berjalan di main thread, sehingga browser tidak dapat merespons dengan cepat.

Cara memperbaiki INP

• Kurangi dan pecah JavaScript: hapus pustaka yang tidak terpakai, lakukan code-splitting, dan muat fitur hanya saat diperlukan
• Pecah tugas panjang: tugas lebih dari 50 md memblokir main thread; serahkan kembali kendali ke browser di antara potongan pekerjaan
• Audit skrip pihak ketiga: tag manager, widget chat, alat pengujian A/B, dan skrip iklan sering menjadi biang masalah
• Jaga DOM tetap ramping: halaman yang sangat besar membuat setiap pembaruan lebih lambat
• Berikan umpan balik visual segera saat interaksi, lalu kerjakan tugas berat setelahnya

Cumulative Layout Shift (CLS)

CLS mengukur pergeseran tata letak yang tidak terduga – pengalaman menjengkelkan saat tombol melompat menjauh tepat ketika Anda mengetuknya. CLS menilai seberapa banyak konten bergeser dan seberapa jauh.

Cara memperbaiki CLS

• Tetapkan lebar dan tinggi pada gambar dan video, atau gunakan CSS aspect-ratio, agar ruang disediakan
• Sediakan ruang untuk iklan, embed, dan iframe dengan wadah berukuran tetap
• Hindari menyisipkan konten di atas konten yang sudah ada, seperti banner yang mendorong halaman ke bawah setelah dimuat
• Gunakan font-display: swap dengan hati-hati dan preload web font utama, atau gunakan metrik font cadangan agar teks tidak berubah alur
• Animasikan dengan transform, bukan properti seperti top atau height yang memicu perhitungan ulang tata letak

Alur kerja praktis

1. Periksa laporan Core Web Vitals di Search Console untuk melihat kelompok URL mana yang gagal dan pada metrik apa
2. Pilih URL yang mewakili dari setiap kelompok yang gagal
3. Jalankan uji lab untuk mendiagnosis apa yang lambat
4. Perbaiki di tingkat template – sebagian besar masalah memengaruhi setiap halaman dengan tata letak yang sama
5. Validasi: di Search Console, mulai validasi setelah deploy; data lapangan membutuhkan hingga 28 hari untuk mencerminkan perbaikan

Seberapa besar pengaruh Core Web Vitals pada peringkat?

Google telah menegaskan bahwa pengalaman halaman adalah satu sinyal di antara banyak sinyal, dan relevansi serta konten yang bermanfaat lebih penting. Halaman cepat dengan konten lemah tidak akan mengalahkan halaman yang hebat. Tetapi saat halaman sama relevannya, pengalaman yang lebih baik dapat membantu – dan halaman yang lebih cepat secara konsisten menghasilkan konversi lebih baik, yang penting terlepas dari peringkat.

Tips khusus platform

WordPress

• Gunakan plugin cache atau cache tingkat hosting untuk memangkas waktu respons server
• Pilih tema yang ringan; page builder berat sering menambahkan banyak CSS dan JavaScript
• Audit plugin: masing-masing dapat menambahkan skrip ke setiap halaman sehingga merusak INP
• Gunakan plugin optimasi gambar yang menyajikan WebP atau AVIF dan menambahkan atribut lebar dan tinggi
• Tunda atau hapus skrip pihak ketiga yang tidak Anda perlukan di setiap halaman

Shopify

• Tinjau aplikasi yang terpasang – banyak yang menyisipkan skrip di setiap halaman meski tidak dipakai
• Gunakan fitur gambar responsif bawaan tema
• Batasi jumlah section dan slider di beranda
• Kompres dan ubah ukuran gambar sebelum diunggah

Situs custom dan yang berat JavaScript

• Gunakan rendering sisi server atau pembuatan statis agar konten muncul tanpa menunggu JavaScript
• Lakukan code-splitting per route dan muat komponen sesuai kebutuhan
• Ukur INP pengguna nyata dengan pustaka JavaScript web-vitals dan kirim ke analitik, agar Anda tahu interaksi mana yang lambat

Mengukur data pengguna nyata sendiri

Search Console dan PageSpeed Insights menampilkan data Chrome yang diagregasi, tetapi hanya untuk halaman dengan cukup trafik dan dengan jeda waktu. Untuk melihat Core Web Vitals setiap halaman dan setiap pengunjung, tambahkan real-user monitoring (RUM). Pustaka open-source web-vitals melaporkan LCP, INP, dan CLS dari browser pengunjung; Anda dapat mengirim nilainya ke Google Analytics 4 atau alat analitik lain. RUM juga mencatat elemen mana yang menjadi LCP dan interaksi mana yang paling lambat – persis yang Anda butuhkan untuk memperbaiki masalah.

Catatan tentang Total Blocking Time dan Speed Index

Lighthouse melaporkan metrik lain selain Core Web Vitals. Total Blocking Time (TBT) mengukur berapa lama main thread terblokir selama pemuatan dan berkorelasi dengan INP. First Contentful Paint (FCP) menandai saat sesuatu pertama kali muncul. Speed Index mengukur seberapa cepat area yang terlihat terisi. Metrik ini berguna untuk diagnosis tetapi bukan Core Web Vitals itu sendiri.

Mitos umum

• “Skor PageSpeed 100 wajib untuk berperingkat.” Tidak. Yang dihitung untuk pengalaman halaman adalah lolos ambang batas Core Web Vitals pada data lapangan, dan relevansi jauh lebih penting.
• “Core Web Vitals hanya penting untuk Google.” Halaman yang lebih cepat dan stabil meningkatkan konversi dan kepuasan setiap pengunjung, dari mana pun mereka datang.
• “Menambah plugin cache membantu.” Menumpuk beberapa plugin cache atau optimasi sering menimbulkan konflik. Gunakan satu solusi yang dikonfigurasi dengan baik.

Poin-poin penting

• Core Web Vitals mengukur pemuatan (LCP), responsivitas (INP), dan stabilitas visual (CLS).
• Ambang batas yang baik adalah LCP ≤ 2,5 dtk, INP ≤ 200 md, dan CLS ≤ 0,1 pada persentil ke-75 kunjungan nyata.
• Yang dihitung adalah data lapangan dari pengguna Chrome nyata; uji lab untuk mendiagnosis masalah.
• LCP biasanya membaik dengan server yang lebih cepat dan gambar hero yang lebih teroptimasi.
• INP membaik saat Anda mengurangi dan memecah JavaScript, terutama skrip pihak ketiga.
• CLS membaik saat Anda menyediakan ruang untuk gambar, iklan, dan embed.

Pertanyaan yang sering diajukan

Mengapa skor lab dan lapangan saya berbeda?

Uji lab menyimulasikan satu perangkat dan jaringan. Data lapangan mencerminkan perangkat, jaringan, dan perilaku pengunjung nyata Anda, termasuk interaksi yang tidak dilakukan uji lab.

Berapa lama sampai perbaikan terlihat di Search Console?

Data lapangan mencakup 28 hari sebelumnya, jadi perlu hingga empat minggu agar perbaikan tercermin sepenuhnya.

Apakah Core Web Vitals penting di desktop?

Ya. Google menilai seluler dan desktop secara terpisah. Seluler biasanya lebih sulit lolos karena perangkat dan jaringannya lebih lambat.

Berapa skor PageSpeed yang baik?

90 ke atas tergolong baik. Namun skor itu ringkasan lab; yang dihitung untuk pengalaman halaman adalah lolos Core Web Vitals pada data lapangan.