Daftar isi
Website dapat terlihat selesai tetapi masih terasa lambat ketika pengguna membuka halaman atau menekan tombol. Core Web Vitals membantu memisahkan masalah pemuatan, respons interaksi, dan kestabilan tampilan sehingga tim tidak hanya mengejar satu angka audit tanpa memahami pengalaman pengunjung.
Yang perlu Anda pertimbangkan
- Ambang baik adalah LCP ≤ 2,5 detik, INP ≤ 200 milidetik, dan CLS ≤ 0,1.
- Penilaian Core Web Vitals menggunakan persentil ke-75 data lapangan, dipisahkan menurut mobile dan desktop.
- Gunakan pengujian laboratorium untuk diagnosis dan data pengguna nyata untuk memeriksa pengalaman sebenarnya.
Tiga metrik menjawab tiga masalah berbeda
LCP atau Largest Contentful Paint mengukur waktu tampilnya elemen konten terbesar yang terlihat di viewport. Elemen tersebut sering berupa gambar hero atau blok teks besar. INP atau Interaction to Next Paint menilai respons halaman terhadap interaksi pengguna selama kunjungan. CLS atau Cumulative Layout Shift mengukur pergeseran tata letak yang tidak diharapkan.
Ketiganya saling melengkapi. Hero dapat tampil cepat tetapi menu tetap lambat merespons karena browser sibuk menjalankan JavaScript. Halaman juga bisa terasa cepat namun menggeser tombol saat gambar muncul, sehingga pengguna menekan bagian yang salah. Perbaikan perlu mengikuti metrik dan penyebabnya, bukan sekadar mengganti hosting.
Baca ambang baik bersama persentil ke-75
Panduan web.dev menetapkan ambang berikut untuk pengalaman yang dinilai baik. Sebuah halaman dinyatakan memenuhi penilaian Core Web Vitals ketika ketiga metrik memenuhi target pada persentil ke-75, dengan perangkat mobile dan desktop dinilai terpisah.
Persentil ke-75 bukan nilai rata-rata dan bukan hasil terbaik. Secara sederhana, nilai ini menunjukkan batas yang dicapai oleh sekitar tiga perempat pengamatan yang dinilai. Karena itu, satu pengujian cepat di laptop kantor belum cukup untuk menyimpulkan seluruh pengguna memiliki pengalaman yang baik.
| Metrik | Ambang baik | Contoh masalah yang diperiksa |
|---|---|---|
| LCP | 2,5 detik atau kurang | Gambar utama terlambat ditemukan atau terlalu berat |
| INP | 200 milidetik atau kurang | Menu atau filter lambat memberi perubahan visual |
| CLS | 0,1 atau kurang | Teks dan tombol bergeser setelah aset dimuat |
Bedakan data lapangan dengan simulasi laboratorium
Data lapangan berasal dari pengalaman pengguna nyata yang memenuhi syarat pengumpulan data. Laporan berbasis Chrome UX Report umumnya memakai jendela bergulir 28 hari. Website baru atau halaman dengan data yang belum cukup bisa belum memiliki laporan per URL; ketiadaan data bukan bukti lulus atau gagal.
Pengujian laboratorium menggunakan kondisi terkontrol untuk mengungkap penyebab masalah. Hasilnya dipengaruhi perangkat simulasi, jaringan, cache, dan beban pengujian. Audit pemuatan biasa juga tidak merekam seluruh interaksi sepanjang kunjungan, sehingga diagnosis INP perlu mencakup percobaan interaksi. Catat kondisi pengujian agar perbandingan sebelum dan sesudah bermakna.
Hubungkan setiap metrik dengan pekerjaan yang konkret
Untuk LCP, identifikasi elemen terbesar yang sebenarnya diukur. Periksa respons server, penemuan aset, ukuran unduhan, dan waktu render. Mengompresi semua gambar di footer tidak banyak membantu jika penyebab utamanya adalah gambar hero yang baru diminta setelah JavaScript selesai.
Untuk INP, coba menu, pencarian, filter, dan formulir pada halaman yang bermasalah. Cari pekerjaan berat yang menahan pembaruan tampilan. Untuk CLS, amati kapan konten bergeser: gambar tanpa ruang, font yang mengubah ukuran teks, atau banner yang disisipkan di atas konten dapat menjadi penyebab.
- Perbaiki halaman masuk dan alur bisnis penting sebelum mengejar detail yang jarang dipakai.
- Pisahkan perubahan agar penyebab perbaikan atau kemunduran mudah dikenali.
- Periksa fungsi dan tampilan setelah optimasi; halaman cepat tetap harus dapat digunakan.
Contoh evaluasi yang tidak terjebak skor
Misalkan halaman layanan memiliki gambar pembuka berat dan tombol konsultasi yang tertutup ketika font selesai dimuat. Tim dapat menyiapkan gambar sesuai ukuran layar, memastikan gambar utama diminta segera, dan menyediakan ruang tata letak yang stabil. Catat hasil pengujian ulang pada kondisi yang sama, kemudian pantau data lapangan setelah perubahan berjalan.
Jangan mengubah contoh tersebut menjadi janji bahwa setiap perbaikan akan menghasilkan kenaikan penjualan atau peringkat. Core Web Vitals menggambarkan sebagian pengalaman halaman. Kesesuaian penawaran, kualitas isi, kepercayaan, dan proses tindak lanjut tetap memengaruhi hasil bisnis.
Jadikan performa sebagai pemeriksaan berulang
Konten baru, gambar portofolio, widget pemasaran, dan pembaruan aplikasi dapat mengubah performa setelah peluncuran. Tetapkan halaman contoh serta kondisi uji yang disepakati. Periksa kembali setelah perubahan yang menambah aset atau interaksi, kemudian prioritaskan temuan berdasarkan dampaknya pada pengguna.
Simpan catatan metrik, tanggal rilis, dan perubahan utama agar tim dapat menghubungkan masalah dengan penyebab yang mungkin. Target internal boleh lebih ketat daripada ambang Core Web Vitals, tetapi selalu tulis apakah target berasal dari laboratorium atau lapangan. Dua jenis angka itu tidak boleh disajikan sebagai hal yang sama.
Pertanyaan yang sering muncul
Apakah skor Lighthouse 100 berarti pasti lulus Core Web Vitals?
Tidak. Lighthouse adalah pengujian laboratorium dalam kondisi tertentu, sedangkan penilaian Core Web Vitals mengandalkan metrik lapangan pada persentil ke-75. Gunakan keduanya untuk tujuan yang berbeda.
Mengapa perbaikan belum langsung terlihat pada laporan lapangan?
Laporan bergulir masih mencakup kunjungan sebelum perubahan. Periksa penerapan lewat pengujian terkontrol, lalu pantau perkembangan data lapangan sambil memastikan jumlah data dan kelompok perangkat yang dibandingkan sesuai.
Rujukan
Tentukan langkah yang sesuai bisnis Anda.
Bawa contoh alur kerja, kendala saat ini, dan prioritas Anda. Tim Metanotech membantu membahas cakupan, pilihan solusi, serta tahapan pengerjaannya.
