Core Web Vitals: ukur, diagnosis, dan perbaiki pengalaman

Core Web Vitals menilai pemuatan, respons interaksi, dan stabilitas tampilan. Gunakan data pengguna untuk menilai pengalaman, pengujian lab untuk mencari penyebab, dan pemeriksaan fungsi untuk memastikan perubahan tidak merusak website. Skor Lighthouse bukan status lulus field atau ukuran hasil bisnis.

Diperbarui 11 Oktober 2026. Contoh dan simulasi dibedakan dari hasil klien yang terukur.

Apa itu LCP, INP, dan CLS?

LCP mengukur waktu tampilnya elemen konten terbesar yang memenuhi kriteria. INP menilai latensi klik, tap, dan keyboard sampai paint berikutnya, dengan aturan pengecualian outlier; bukan durasi seluruh proses jaringan. CLS mengukur pergeseran layout yang tidak diharapkan. INP menggantikan FID sebagai Core Web Vital pada Maret 2024. Penjelasan INP.

Mengapa pengalaman perlu dinilai dari pengguna Anda?

Perangkat, jaringan, lokasi, halaman masuk, dan cara berinteraksi memengaruhi pengalaman. Jangan menggunakan angka persentase pengguna ponsel nasional sebagai pengganti data website Anda. Periksa segmen perangkat dan halaman penting, termasuk formulir dan menu. Kecepatan yang lebih baik dapat mengurangi hambatan, tetapi pengaruh pada inquiry harus diukur, bukan diasumsikan.

Hosting dan CDN: uji jalur yang sebenarnya

Periksa respons server, cache, ukuran aset, dan rute jaringan dari lokasi pengguna yang relevan. CDN tidak otomatis memperbaiki JavaScript berat atau gambar hero yang ditemukan terlambat. Bandingkan cache hit dan miss, biaya, konfigurasi, serta dependensi pihak ketiga. Pilih perubahan setelah melihat bukti hambatan; lokasi server saja tidak membuktikan performa atau ROI.

Ambang good dan cara menilainya

Evaluasi field menggunakan persentil ke-75 dan pisahkan perangkat. LCP 2,6 detik berada pada needs improvement, walaupun merupakan kemajuan dari kondisi lebih lambat. Jika sampel CrUX tidak tersedia, statusnya belum terukur melalui sumber tersebut, bukan otomatis lulus. Panduan Core Web Vitals.

Diagnosis LCP: dari respons hingga render

Identifikasi elemen LCP pada halaman dan perangkat yang diuji. Pisahkan waktu respons dokumen, penemuan resource, unduh resource, dan penundaan render. Jika hero menjadi elemen LCP, gunakan ukuran yang sesuai, jalur penemuan awal, dan prioritas yang beralasan; jangan lazy-load gambar utama di atas fold tanpa evaluasi. Optimalkan CSS atau font bila bukti menunjukkan render tertunda. Uji ulang pada kondisi yang sama.

Diagnosis INP: periksa interaksi yang lambat

Rekam interaksi nyata seperti menu, pencarian, FAQ, dan submit form. Pisahkan input delay, pekerjaan handler, dan penundaan presentasi. Cari long task, JavaScript pihak ketiga, render berulang, atau layout yang mahal. Jumlah tag GTM tidak menentukan INP dengan sendirinya. Kurangi pekerjaan yang terbukti berat, pecah tugas, dan pastikan umpan balik segera terlihat tanpa mengklaim operasi sudah selesai.

Diagnosis CLS: temukan elemen yang bergeser

Periksa gambar tanpa ruang yang dipesan, perubahan font, banner yang disisipkan, dan embed yang mengubah tinggi. Tetapkan dimensi atau rasio pada media dan ruang yang sesuai untuk komponen dinamis. Bedakan pergeseran tak terduga dari perubahan yang berkaitan dengan interaksi sesuai aturan metrik. Periksa crop, keterbacaan, dan navigasi setelah perbaikan; menghilangkan elemen penting bukan solusi hanya demi skor.

CWV, SEO, dan visibilitas AI

CWV berkaitan dengan pengalaman halaman dan digunakan dalam sistem ranking Google. Memenuhi ambang tidak menjamin ranking, sementara kegagalan CWV bukan larangan indeks universal. Tidak ada bukti bahwa skor CWV tertentu menjadi syarat sitasi semua produk AI. Halaman tetap memerlukan informasi relevan, akses yang sesuai, dan fungsi yang dapat digunakan.

Bacaan terkait: Menentukan prioritas pencarian; Menata fungsi halaman.

Workflow audit dan verifikasi

Minta pengembang menghubungkan setiap rekomendasi dengan bukti dari URL dan interaksi yang diuji. Nama framework atau penyedia hosting saja tidak menjelaskan penyebab perlambatan. Simpan trace, daftar perubahan, serta cara mengembalikan versi sebelumnya; kemudian uji kembali halaman dan fungsi yang sama setelah rilis.

Target per template tanpa hasil klien rekaan

Ambang good tidak berubah menurut jenis website. Prioritas pekerjaan yang berbeda: artikel dapat didominasi hero dan font, toko oleh daftar produk serta interaksi keranjang, halaman konsultasi oleh script dan formulir. Simulasi: tim menerima perbaikan LCP dari 4,1 ke 2,6 detik sebagai kemajuan, tetapi mencatat bahwa kategori masih needs improvement. Angka tersebut ilustrasi klasifikasi, bukan hasil proyek atau perubahan konversi.

Monitoring berkelanjutan dan jendela data

CrUX merangkum data dalam jendela bergulir 28 hari, bukan pembaruan satu kali setelah tepat 28 hari. Laporan GSC mengelompokkan URL dan dapat memiliki jeda pemrosesan. Pantau perubahan template, script, dan aset dengan log rilis. Jika data URL tidak ada, bedakan data origin dari halaman spesifik. Jangan memakai data lab sesaat untuk menyatakan seluruh pengguna sudah mendapat pengalaman baru. Dokumentasi CrUX API.

Kesalahan yang perlu dihindari

Jangan mengejar skor tanpa menguji CTA, form, consent, dan keyboard. Jangan mengompresi ilustrasi hingga label tidak terbaca. Jangan menambah preload semua aset atau menghapus pengukuran tanpa persetujuan. Jangan menyebut cache atau CDN pasti balik modal. Catat biaya serta perubahan inquiry bila evaluasi bisnis diperlukan; perbandingan sebelum–sesudah tetap memiliki keterbatasan kausalitas.

Kapan membutuhkan bantuan profesional?

Minta bantuan ketika hambatan memerlukan profiling, perubahan server, atau koordinasi banyak template. Brief harus menetapkan URL prioritas, fungsi yang dijaga, sumber baseline, target pekerjaan, dan cara rollback. Keberhasilan dinilai dari bukti pengalaman dan fungsi, bukan janji ranking atau sebuah angka Lighthouse saja.

Bacaan terkait: Brief perubahan website; Pengukuran inquiry yang valid.