Core Web Vitals Dijelaskan untuk Developer

Setiap kali saya diskusi soal performa web dengan tim frontend, ujung-ujungnya selalu balik ke tiga metrik ini: LCP, CLS, dan INP. Bukan kebetulan — ketiganya adalah Core Web Vitals, metrik yang dipakai Google sebagai sinyal ranking dan, yang lebih penting buat saya sebagai praktisi, indikator nyata seberapa "enak" sebuah aplikasi dipakai. Masalahnya, banyak developer tahu singkatannya tapi tidak benar-benar paham apa yang diukur dan kenapa metrik itu bisa jelek. Akibatnya perbaikan yang dilakukan sering salah sasaran — misalnya sibuk optimasi ukuran gambar padahal skor CLS yang jeblok justru karena iklan yang muncul belakangan.

Di tulisan ini saya coba bedah ketiganya dari sudut pandang praktis: apa yang sebenarnya diukur, dan penyebab umum yang biasanya bikin angkanya memburuk.

LCP: seberapa cepat konten utama terlihat

Largest Contentful Paint mengukur waktu sampai elemen terbesar yang terlihat di viewport — biasanya gambar hero, video thumbnail, atau blok teks besar — selesai dirender. Ini bukan soal "halaman selesai loading", tapi soal kapan pengguna merasa "oh, ini isinya sudah muncul".

Penyebab LCP jelek yang paling sering saya temui di lapangan:

Server response time yang lambat (TTFB tinggi), misalnya karena query database berat dijalankan sebelum halaman bisa dikirim.
Render-blocking resources — CSS atau JavaScript besar yang harus selesai dimuat dulu sebelum browser bisa menggambar konten.
Gambar hero yang tidak dioptimasi ukurannya, atau dimuat lewat JavaScript sehingga browser tidak bisa mulai mengunduhnya lebih awal.
Font kustom yang memblokir render teks (kalau tidak diatur strategi font-display-nya).

Prinsip umumnya: elemen LCP harus bisa ditemukan browser secepat mungkin dari HTML awal, bukan disuntikkan belakangan lewat client-side rendering.

CLS: kestabilan visual, bukan kecepatan

Cumulative Layout Shift berbeda karakter — ini soal seberapa banyak elemen di halaman "bergeser" tanpa diduga saat halaman dimuat atau saat pengguna berinteraksi. Kasus klasik yang pasti pernah kita alami sebagai pengguna: mau tap tombol, tiba-tiba iklan muncul di atasnya dan kita malah tap yang lain.

Penyebab umum CLS tinggi:

Gambar atau video tanpa atribut width/height, sehingga browser tidak tahu berapa ruang yang harus disediakan sebelum aset itu selesai dimuat.
Iklan, embed, atau widget pihak ketiga yang di-inject secara dinamis tanpa alokasi ruang.
Font web yang menyebabkan FOIT/FOUT — teks berganti ukuran/font setelah font kustom selesai dimuat.
Konten yang disisipkan secara dinamis di atas konten yang sudah ada (misalnya notifikasi banner yang muncul mendadak di bagian atas halaman).

Solusi paling ampuh biasanya sederhana: selalu sediakan ruang (reserve space) untuk elemen yang ukurannya belum pasti, lewat CSS aspect-ratio atau dimensi eksplisit, sebelum konten sebenarnya datang.

INP: seberapa responsif aplikasi saat dipakai

Interaction to Next Paint ini yang paling baru dan menurut saya paling relevan buat aplikasi dashboard-style (mirip yang biasa saya bangun dengan Laravel + Vue). INP mengukur latensi dari saat pengguna berinteraksi — klik, tap, ketik — sampai browser benar-benar menampilkan hasil visualnya di layar.

Penyebab umum INP jelek:

JavaScript thread utama yang sibuk (long tasks) — misalnya perhitungan berat atau parsing data besar yang dijalankan langsung di main thread saat interaksi terjadi.
Event handler yang melakukan terlalu banyak pekerjaan sinkron, termasuk re-render komponen yang tidak perlu.
Terlalu banyak DOM node yang harus di-update sekaligus (sering terjadi di tabel data besar tanpa virtualisasi).
Third-party script (analytics, chat widget, dsb) yang memblokir main thread di waktu yang tidak tepat.

Sebagai ilustrasi, kalau sebuah tombol "Simpan" di form panjang butuh waktu terasa lama sebelum ada feedback visual, itu gejala klasik INP buruk — biasanya karena validasi atau serialisasi data dijalankan secara sinkron dan memblokir render berikutnya.

Takeaway

Ketiga metrik ini sebenarnya menceritakan tiga fase pengalaman berbeda: LCP soal "kapan saya lihat isinya", CLS soal "apakah tampilannya stabil", dan INP soal "apakah aplikasinya responsif saat saya pakai". Kalau mau ngoprek performa secara efektif, jangan optimasi buta — ukur dulu pakai tools seperti Lighthouse atau Chrome UX Report untuk tahu metrik mana yang sebenarnya bermasalah, baru cari penyebabnya dari daftar di atas. Perbaikan yang tepat sasaran jauh lebih murah daripada "optimasi umum" yang menyentuh semua bagian tapi tidak menyelesaikan akar masalahnya.