Core Web Vitals dijelaskan: LCP, INP, dan CLS dalam bahasa sederhana

Core Web Vitals bukan tes kepribadian untuk website Anda

Core Web Vitals sering diperlakukan seperti kartu skor yang misterius. Sebuah halaman mendapat angka merah, seseorang mengunggah tangkapan layar di Slack, lalu tim mulai berdebat tentang framework JavaScript.

Itu tidak terlalu berguna.

Cara yang lebih baik untuk memikirkan Core Web Vitals lebih sederhana: metrik ini adalah tiga pengukuran tentang apakah sebuah halaman terasa dapat digunakan oleh orang sungguhan di perangkat sungguhan. Metrik ini tidak menangkap setiap aspek performa, aksesibilitas, atau kualitas. Namun, metrik ini menangkap tiga sumber frustrasi yang umum:

• Konten utama terlalu lama muncul.
• Halaman bereaksi lambat saat pengguna mencoba melakukan sesuatu.
• Tata letak bergeser-geser saat pengguna sedang membaca atau mengetuk.

Itulah tiga Core Web Vitals: LCP, INP, dan CLS.

Google menggunakannya sebagai bagian dari sinyal pengalaman halaman, tetapi sudut pandang SEO bukan alasan terbaik untuk peduli. Alasan yang lebih baik adalah bahwa halaman yang lambat, suka bergeser, dan tidak responsif membuang waktu pengguna. Halaman seperti itu juga cenderung memiliki konversi lebih buruk, dukungan lebih buruk, dan menua dengan buruk.

Tiga metrik dalam masing-masing satu kalimat

Sebelum masuk ke detail, berikut versi bahasa sederhananya:

• LCP, atau Largest Contentful Paint, mengukur berapa lama konten utama yang terlihat dimuat.
• INP, atau Interaction to Next Paint, mengukur seberapa cepat halaman merespons interaksi pengguna sepanjang kunjungan.
• CLS, atau Cumulative Layout Shift, mengukur seberapa banyak halaman bergerak secara tidak terduga.

Ambang batas yang umum adalah:

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2.5s atau lebih cepat | 2.5s–4.0s | Di atas 4.0s | | INP | 200ms atau lebih cepat | 200ms–500ms | Di atas 500ms | | CLS | 0.1 atau lebih rendah | 0.1–0.25 | Di atas 0.25 |

Angka-angka ini biasanya dievaluasi pada persentil ke-75 dari kunjungan pengguna nyata. Itu penting. Anda tidak sedang mencoba membuat satu pengujian lab yang sempurna. Anda sedang mencoba membuat pengalaman yang baik bagi sebagian besar pengguna, termasuk orang-orang dengan ponsel yang lebih lambat dan jaringan yang lebih tidak stabil.

Jika Anda sedang menatap laporan otomatis dan tidak yakin harus mulai dari mana, ada baiknya memisahkan diagnosis dari kepanikan. Kami memiliki panduan terpisah tentang cara membaca laporan Lighthouse tanpa panik yang membahas alur kerja itu secara lebih detail.

LCP: kapan halaman terasa sudah dimuat?

Largest Contentful Paint mengukur waktu render elemen konten terlihat terbesar di viewport. Dalam praktiknya, itu sering berupa:

• gambar hero,
• judul besar,
• gambar artikel unggulan,
• gambar produk,
• blok teks besar.

LCP tidak menanyakan kapan setiap script, tracking pixel, dan gambar di bawah lipatan selesai dimuat. LCP menanyakan: kapan hal utama yang ingin dilihat pengguna menjadi terlihat?

Ini membuat LCP menjadi metrik yang lebih manusiawi daripada “waktu muat halaman” gaya lama. Sebuah halaman secara teknis bisa selesai dimuat terlambat tetapi tetap terasa cepat jika konten utama muncul dengan cepat. Kebalikannya juga benar: sebuah halaman bisa memicu event load saat area hero masih kosong, buram, atau tertahan oleh penundaan render.

Penyebab umum LCP yang buruk

Sebagian besar masalah LCP yang buruk berasal dari beberapa tempat yang mudah diprediksi:

1. Respons server lambat

Jika dokumen HTML datang terlambat, semua hal lain ikut mulai terlambat.

1. CSS atau JavaScript yang memblokir render

Browser sudah memiliki kontennya, tetapi belum bisa menggambarnya.

1. Gambar hero yang tidak dioptimalkan

Elemen terbesar terlalu besar, menggunakan format yang salah, tidak diprioritaskan, atau keliru dimuat secara lazy.

1. Web fonts yang menunda rendering teks

Judul besar mungkin menjadi elemen LCP, dan pemuatan font dapat menunda atau mengubah tampilannya secara visual.

1. Penundaan client-side rendering

Jika halaman membutuhkan bundle JavaScript besar sebelum dapat menampilkan konten bermakna, LCP akan terdampak.

Cara meningkatkan LCP

Mulailah dari elemen LCP yang sebenarnya. Jangan mengoptimalkan aset acak sebelum Anda tahu apa yang sedang diukur browser.

Perbaikan praktis meliputi:

• Sajikan HTML dengan cepat: gunakan cache jika sesuai, kurangi pekerjaan backend, hindari redirect lambat.
• Optimalkan gambar LCP: gunakan dimensi, kompresi, dan format yang tepat.
• Jangan melakukan lazy-load pada gambar hero above-the-fold.
• Gunakan fetchpriority="high" dengan hati-hati untuk gambar utama saat gambar itu benar-benar menjadi prioritas.
• Inline critical CSS hanya saat itu benar-benar mengurangi penundaan render secara bermakna.
• Kurangi JavaScript yang dibutuhkan sebelum render bermakna pertama.
• Gunakan font-display: swap atau strategi font lain yang disengaja.

Gambar dan font sering menjadi penyebab. Untuk gambar, trade-off-nya bukan sekadar “file kecil itu baik”. Pilihan format, upaya encoding, dan dukungan browser semuanya penting, itulah sebabnya kami menyimpan pohon keputusan praktis untuk kapan AVIF mengalahkan WebP dan kapan tidak. Untuk halaman yang berat teks, web fonts masih menjadi salah satu kemenangan performa termudah karena banyak situs mengirim lebih banyak file font daripada yang mereka gunakan.

INP: apakah halaman merespons saat disentuh?

Interaction to Next Paint mengukur responsivitas. Lebih spesifik lagi, metrik ini melihat jeda antara interaksi pengguna dan pembaruan visual berikutnya setelah browser memproses interaksi tersebut.

Interaksi mencakup hal-hal seperti:

• mengeklik tombol,
• mengetuk menu,
• memilih checkbox,
• mengetik ke dalam field formulir,
• membuka accordion.

INP menggantikan First Input Delay sebagai Core Web Vital pada 2024. Itu perubahan yang baik. First Input Delay hanya melihat interaksi pertama. INP lebih luas: metrik ini mempertimbangkan interaksi sepanjang kunjungan halaman dan melaporkan interaksi dengan latensi tinggi sebagai skor responsivitas halaman.

Dalam bahasa sederhana: INP menangkap halaman yang terlihat sudah dimuat tetapi terasa macet.

Anda mungkin pernah menggunakan halaman seperti ini. Halaman tampak siap. Anda mengetuk menu. Tidak ada yang terjadi selama setengah detik. Anda mengetuk lagi. Lalu dua hal terjadi sekaligus. Itu adalah masalah INP.

Penyebab umum INP yang buruk

INP biasanya merupakan masalah main thread. Browser ingin merespons, tetapi JavaScript, pekerjaan rendering, atau perhitungan layout menghalanginya.

Penyebab yang umum meliputi:

• bundle JavaScript besar,
• event handler yang mahal,
• pekerjaan hydration pada aplikasi yang dirender di client,
• script pihak ketiga yang berebut main thread,
• task berdurasi panjang setelah halaman dimuat,
• pembaruan DOM kompleks yang dipicu oleh interaksi kecil,
• layout thrashing, yaitu ketika kode berulang kali membaca dan menulis nilai layout.

Tag marketing, analytics, widget chat, dan consent banner semuanya dapat berkontribusi. Ini tidak berarti “hapus semuanya”. Artinya, setiap script di halaman memiliki biaya, dan latensi interaksi sering menjadi tempat biaya itu terlihat.

Cara meningkatkan INP

Meningkatkan INP bukan soal satu atribut ajaib, melainkan soal mengurangi perebutan main thread.

Pendekatan yang berguna meliputi:

• Pecah task JavaScript yang panjang menjadi bagian-bagian lebih kecil.
• Tunda pekerjaan non-esensial hingga halaman dapat digunakan.
• Hapus JavaScript yang tidak digunakan, bukan hanya meminifikasinya.
• Jaga event handler tetap kecil dan mudah diprediksi.
• Hindari me-render ulang bagian besar antarmuka untuk perubahan state yang kecil.
• Gunakan CSS untuk state visual sederhana jika memungkinkan.
• Audit script pihak ketiga dan muat hanya di tempat yang diperlukan.

Perhatikan juga desain interaksi. Tombol yang memberi umpan balik visual langsung dapat terasa lebih responsif, meskipun pekerjaan lanjutan memakan waktu lebih lama. Itu bukan pengganti performa, tetapi merupakan bagian dari rekayasa antarmuka yang baik. Checklist kami untuk tombol web yang aksesibel berkaitan dengan ini: state yang jelas, semantik yang tepat, dan perilaku yang dapat diprediksi membantu pengguna sekaligus browser.

CLS: apakah halaman tetap berada di tempat yang diharapkan pengguna?

Cumulative Layout Shift mengukur pergerakan tak terduga dari elemen yang terlihat. Jika pengguna mulai membaca paragraf lalu iklan, gambar, atau banner dimuat di atasnya dan mendorong teks ke bawah, itu berkontribusi pada CLS.

CLS tidak diukur dalam detik. Ini adalah skor berdasarkan seberapa banyak konten bergerak dan seberapa jauh pergerakannya. Semakin rendah semakin baik.

Kata kuncinya adalah tidak terduga. Perubahan layout yang disebabkan oleh tindakan pengguna biasanya tidak dihitung dengan cara yang sama. Jika seseorang mengetuk “tampilkan lebih banyak” dan konten melebar, itu diharapkan. Jika banner newsletter muncul di bagian atas setelah tiga detik dan mendorong semuanya ke bawah, itu tidak diharapkan.

Penyebab umum CLS yang buruk

Kegagalan CLS sering kali hal yang biasa saja:

• gambar tanpa atribut width dan height,
• iklan atau embed tanpa ruang yang dicadangkan,
• cookie banner yang disisipkan di atas konten,
• web fonts yang berganti dengan metrik berbeda,
• bar promosi yang dimuat terlambat,
• konten yang disuntikkan secara dinamis di dekat bagian atas halaman.

Perbaikannya biasanya dengan mencadangkan ruang sebelum konten tiba. Browser seharusnya mengetahui bentuk halaman sedini mungkin.

Cara meningkatkan CLS

Mulailah dari pergeseran yang terlihat. Tonton rekaman atau gunakan tooling browser untuk mengidentifikasi elemen mana yang bergerak.

Lalu terapkan perbaikan yang membosankan:

• Tambahkan atribut width dan height eksplisit pada gambar.
• Gunakan CSS aspect-ratio untuk container media responsif.
• Cadangkan ruang tetap atau minimum untuk iklan, embed, dan iframe.
• Hindari menyisipkan banner di atas konten yang sudah ada setelah load.
• Pilih font fallback dengan metrik yang mirip dengan font akhir.
• Hindari animasi yang mengubah properti layout seperti top, left, width, atau height; lebih baik gunakan transform.

CLS adalah salah satu dari sedikit metrik performa di mana disiplin mengalahkan kecerdikan. Jika halaman memiliki kotak-kotak yang stabil, skornya cenderung baik.

Field data dan lab data sama-sama berguna, tetapi menjawab pertanyaan yang berbeda

Sumber kebingungan yang umum adalah bahwa alat yang berbeda menampilkan angka yang berbeda. Itu normal.

Field data berasal dari pengguna nyata. Data ini mencerminkan perangkat, jaringan, lokasi, dan kondisi browser yang sebenarnya. Google’s Chrome User Experience Report adalah contoh field data.

Lab data berasal dari lingkungan pengujian terkontrol. Lighthouse adalah contoh yang familiar. Data ini dapat diulang dan berguna untuk debugging, tetapi tidak sama dengan pengalaman nyata pengguna Anda.

Gunakan field data untuk memutuskan apakah pengguna memiliki masalah nyata. Gunakan lab data untuk mereproduksi dan men-debug masalah tersebut.

Ingat juga bahwa Core Web Vitals biasanya dinilai per URL atau kelompok URL, bukan sebagai satu properti abstrak dari brand Anda. Halaman beranda, artikel blog, halaman harga, dan checkout dapat memiliki bottleneck yang sangat berbeda.

Urutan kerja yang masuk akal

Jika ketiga metrik buruk, godaannya adalah memulai dari mana-mana. Tahan godaan itu.

Urutan praktisnya adalah:

1. Perbaiki CLS yang jelas terlebih dahulu

Dimensi gambar yang hilang dan banner yang tidak stabil sering menjadi quick win.

1. Tingkatkan LCP untuk template penting

Fokus pada halaman yang penting: halaman produk, landing page, artikel, alur pendaftaran.

1. Selidiki INP dengan interaksi nyata

Klik hal-hal yang benar-benar diklik pengguna. Menu, filter, formulir, dan kontrol checkout sering mengungkap lebih banyak daripada trace pemuatan awal.

1. Audit script pihak ketiga

Pertahankan yang sepadan dengan biayanya. Hapus atau tunda yang tidak.

1. Tetapkan performance budget

Tanpa budget, peningkatan performa akan menurun. Script, gambar, dan komponen desain baru diam-diam akan membatalkan pekerjaan yang sudah dilakukan.

Poin pentingnya: jangan mengoptimalkan demi badge. Optimalkan demi perjalanan pengguna. Peningkatan skor kecil pada halaman dengan traffic rendah mungkin kurang penting dibanding interaksi checkout yang sedikit tidak sempurna tetapi jauh lebih cepat.

<!-- tool-cta:start -->

💡 Coba ini: Karena LCP biasanya masalah gambar, perkecil aset hero Anda dengan Image Compressor sebagai kemenangan mudah pertama.

<!-- tool-cta:end -->

Apa yang tidak diberitahukan oleh Core Web Vitals

Core Web Vitals berguna, tetapi tidak lengkap.

Metrik ini tidak memberi tahu apakah konten Anda bagus. Metrik ini tidak memberi tahu apakah navigasi Anda masuk akal. Metrik ini tidak menjamin aksesibilitas. Metrik ini tidak mengukur privasi, keamanan, kepercayaan, keterbacaan, atau apakah halaman menjawab pertanyaan pengguna.

Metrik ini juga tidak menggantikan penilaian. Sebuah halaman bisa lolos Core Web Vitals dan tetap tidak menyenangkan. Aplikasi yang kompleks bisa gagal memenuhi ambang batas namun tetap direkayasa secara bertanggung jawab sesuai batasannya.

Perlakukan LCP, INP, dan CLS seperti alarm asap. Saat berbunyi, selidiki. Saat diam, tetap rawat bangunannya.