"Website kami cepat kok saat dibuka di kantor. Kira-kira hitungan detiklah."
Penilaian seperti ini wajar. Kebanyakan orang menilai kecepatan website dari pengalaman sendiri, di perangkat sendiri, dengan koneksi kantor yang stabil.
Namun, calon pembeli dan calon tamu tidak membuka website dari laptop kantor Anda.
Mereka membukanya dari ponsel, di jaringan seluler, sering kali di tengah aktivitas lain. Selain itu, kecepatan website ideal saat ini tidak lagi diukur dari satu angka detik. Google memakai 3 metrik yang masing-masing menilai aspek pengalaman yang berbeda.
Artikel ini menjelaskan ambang resmi ketiga metrik tersebut dan cara membacanya. Setelah itu, kita bahas cara mengeceknya sendiri dan kapan hasilnya menandakan perlu optimasi atau revamp.
Semua ambang di artikel ini diambil dari dokumentasi web.dev dan Google Search Central, diakses pada 26 Oktober 2026.
Berapa Kecepatan Website Ideal Menurut Core Web Vitals?
Kecepatan website ideal menurut Core Web Vitals adalah LCP 2,5 detik atau kurang, INP 200 milidetik atau kurang, dan CLS 0,1 atau kurang. Angka ini harus tercapai pada persentil ke-75 kunjungan nyata, dihitung terpisah untuk ponsel dan desktop. Website yang memenuhi ketiganya masuk kategori "baik".
Metrik | Bagian Pengukuran | Baik | Perlu perbaikan | Buruk |
LCP (Largest Contentful Paint) | Waktu tampil elemen terbesar di layar | 2,5 detik atau kurang | Di atas 2,5 sampai 4,0 detik | Lebih dari 4,0 detik |
INP (Interaction to Next Paint) | Respons halaman terhadap klik, ketuk, atau ketikan | 200 milidetik atau kurang | Di atas 200 sampai 500 milidetik | Lebih dari 500 milidetik |
CLS (Cumulative Layout Shift) | Pergeseran tata letak yang tidak diharapkan | 0,1 atau kurang | Di atas 0,1 sampai 0,25 | Lebih dari 0,25 |
Ambang di tabel diambil dari tiga halaman resmi:
web.dev LCP (diperbarui 4 September 2025),
web.dev INP (diperbarui 2 September 2025),
web.dev CLS (diperbarui 12 April 2023).
Ketiganya kami akses pada 26 Oktober 2026.
Oh ya, INP baru resmi menjadi Core Web Vital pada Maret 2024. Metrik ini menggantikan FID (First Input Delay), menurut pengumuman web.dev. Artikel lama yang masih membahas FID sebagai patokan utama sudah tidak sesuai dengan standar saat ini.
Kecepatan Website Tidak Hanya Ukuran Detik
Selama bertahun-tahun, kecepatan website yang dibicarakan: berapa detik halaman selesai dimuat?
Cara tersebut mudah dipahami, tetapi tidak menggambarkan pengalaman pengunjung secara utuh.
Bayangkan meja resepsionis di sebuah hotel. Tamu menilai pelayanan dari tiga hal. Seberapa cepat ia disapa saat datang dan seberapa cepat pertanyaannya dijawab. Lalu, apakah ia dipindah-pindah antrean tanpa alasan. Resepsionis yang cepat menyapa tetapi lambat menjawab tetap meninggalkan kesan buruk.
Core Web Vitals bekerja dengan logika yang sama. LCP menilai seberapa cepat konten utama tampil. INP menilai seberapa cepat halaman merespons tindakan pengunjung. CLS menilai apakah tampilan stabil atau bergeser tiba-tiba. Halaman bisa unggul di satu metrik dan tetap buruk di metrik lain.
Apa Arti LCP, INP, dan CLS bagi Pengunjung Website?
Bagi pengunjung, LCP menentukan seberapa cepat mereka melihat apa yang dicari. INP menentukan apakah tombol dan formulir terasa responsif. CLS menentukan apakah mereka bisa membaca dan mengklik tanpa terganggu.
Ketiganya berpengaruh langsung pada keputusan untuk lanjut menjelajah atau pergi.
LCP: kapan konten utama terlihat

LCP mengukur waktu tampil gambar, blok teks, atau video terbesar yang terlihat di layar. Pada halaman produk manufaktur, elemen ini biasanya foto produk atau judul spesifikasi. Pada website hotel, elemen ini sering berupa foto kamar atau banner promo di bagian atas halaman.
INP: apakah halaman merespons tindakan

INP mengukur seberapa cepat halaman bereaksi setelah pengunjung mengklik, mengetuk, atau mengetik. Contohnya, membuka menu, memilih tanggal di kalender pemesanan, atau mengisi formulir permintaan penawaran. INP yang buruk membuat pengunjung merasa tombolnya tidak berfungsi, lalu mengklik berulang kali.
CLS: apakah tampilan stabil

CLS mengukur pergeseran tata letak yang tidak diharapkan. Contohnya, pengunjung hendak mengklik tombol, lalu sebuah banner atau gambar muncul dan mendorong tombol itu ke bawah. Akibatnya, pengunjung mengklik elemen yang salah.
Berikut video studi kasus website Eonchemicals (klien kami) sebagai gambaran bagaimana CLS diukur.
Kenapa Diukur di Persentil ke-75 dan dari Pengguna Nyata?
Persentil ke-75 dipakai agar mayoritas pengunjung, bukan hanya pengunjung dengan perangkat dan koneksi terbaik, mendapat pengalaman yang baik.
Artinya, minimal 3 dari 4 kunjungan harus memenuhi ambang "baik". Data ini diambil dari pengguna nyata di lapangan, terpisah untuk ponsel dan desktop.
Di sinilah persoalannya menjadi lebih menarik. Ada dua jenis data kecepatan yang sering tertukar:
Data lapangan (field data): diambil dari kunjungan pengguna Chrome yang nyata. Inilah data yang dipakai untuk menilai Core Web Vitals.
Data lab (lab data): hasil simulasi dalam kondisi tertentu, misalnya dari Lighthouse. Berguna untuk mencari penyebab masalah, tetapi tidak selalu sama dengan pengalaman pengunjung sebenarnya.
Karena itu, skor lab yang tinggi belum tentu berarti website lolos Core Web Vitals. Sebaliknya, skor lab yang rendah belum tentu berarti pengunjung mengalami halaman lambat.
Website dengan jumlah pengunjung kecil kadang belum memiliki data lapangan yang cukup, sehingga hanya data lab yang tersedia.
Halaman Lambat Menghambat Pengunjung Melanjutkan ke Tahap Berikutnya
Kecepatan memengaruhi apakah pengunjung bertahan cukup lama untuk melihat produk, membaca penawaran, atau mengisi formulir. Setiap hambatan kecil menambah peluang pengunjung pergi sebelum sampai ke tahap yang menghasilkan inquiry.
Studi Milliseconds Make Millions yang dipublikasikan di web.dev memberi gambaran arahnya. Studi itu juga mencakup situs lead generation. Di sana, perbaikan kecepatan seluler sebesar 0,1 detik berkaitan dengan kenaikan 21,6% pengguna yang melanjutkan ke halaman pengiriman formulir. Yang perlu dicatat, studi ini memakai data akhir 2019 dan sebagian metriknya sudah tidak dipakai lagi.
Dari sisi pencarian, Google Search Central menyatakan Core Web Vitals selaras dengan hal yang ingin dihargai sistem peringkat intinya. Google juga sangat menganjurkan pemilik situs mencapai Core Web Vitals yang baik. Namun, halaman yang sama tidak menyebut kecepatan sebagai satu-satunya penentu peringkat. Konten yang relevan tetap menjadi dasar.
Lalu, apa artinya bagi bisnis?
Ternyata kecepatan bukan sekadar urusan skor. Kecepatan menentukan berapa banyak pengunjung yang sampai ke halaman yang penting bagi penjualan.
Bagi perusahaan manufaktur, halaman yang paling perlu dijaga biasanya halaman katalog dan spesifikasi produk. Di halaman itu calon pembeli membandingkan pemasok. Bagi hotel, halaman kamar hingga alur pemesanan lebih penting daripada beranda, karena di sanalah keputusan menginap diambil.
Gambar Besar, Skrip Pihak Ketiga, dan Server Lambat Menurunkan Skor
Penyebab website lambat jarang tunggal. Namun, ada beberapa pola yang sering muncul pada website perusahaan, terutama yang sudah berjalan bertahun-tahun tanpa evaluasi.
Gambar berukuran besar: foto produk atau banner diunggah dalam resolusi asli tanpa dikompres. Ini sering memperburuk LCP.
Skrip pihak ketiga yang menumpuk: widget chat, pelacak iklan, dan plugin tambahan yang berjalan bersamaan. Ini sering memperburuk INP.
Elemen tanpa ukuran tetap: gambar, iklan, atau banner yang tidak disediakan ruangnya sejak awal. Ini menyebabkan CLS tinggi.
Server lambat merespons: hosting yang kapasitasnya tidak sesuai jumlah pengunjung atau letaknya jauh dari pengunjung utama.
Tema atau plugin yang berat: komponen yang memuat banyak kode, padahal hanya sebagian kecil yang dipakai.
Tapi ini yang sering terlewat.
Website bisa lolos Core Web Vitals saat baru diluncurkan, lalu perlahan memburuk. Setiap plugin baru, tracking script, atau banner promo menambah beban sedikit demi sedikit. Karena itu, kecepatan perlu dipantau sebagai bagian dari perawatan rutin. seperti dibahas di artikel pilar Pentingnya jasa maintenance website perusahaan.
Bagaimana Cara Mengecek Kecepatan Website Sendiri?
Cara paling mudah adalah membuka PageSpeed Insights dan memasukkan alamat halaman. Baca bagian data pengguna nyata lebih dulu, baru setelah itu skor lab.
Untuk gambaran seluruh website, buka laporan Core Web Vitals di Google Search Console. Laporan ini mengelompokkan halaman yang baik, perlu perbaikan, dan buruk.
Langkah praktisnya:
Uji halaman yang paling penting bagi bisnis, bukan hanya beranda. Contohnya, halaman produk utama, halaman paket, dan halaman kontak.
Lihat hasil untuk ponsel lebih dulu, karena sebagian besar pengunjung biasanya datang dari ponsel.
Perhatikan metrik mana yang gagal, lalu catat elemen yang disebut sebagai penyebabnya.
Ulangi pengecekan setelah ada perubahan besar, seperti penambahan plugin, banner, atau halaman baru.
Pilih Optimasi atau Revamp?
Tidak semua website lambat perlu dibangun ulang. Jika masalahnya ada pada gambar, plugin tertentu, atau hosting, optimasi sering sudah cukup.
Revamp layak dipertimbangkan ketika penyebabnya ada di fondasi website, seperti tema yang berat atau struktur yang sulit diubah.
Kondisi | Optimasi biasanya cukup | Revamp layak dipertimbangkan |
Penyebab utama | Gambar besar, plugin tertentu, cache belum aktif | Tema berat, struktur kode lama, banyak komponen saling bergantung |
Metrik yang gagal | Satu metrik, di kategori perlu perbaikan | Beberapa metrik, di kategori buruk |
Hasil setelah perbaikan | Skor membaik dan bertahan | Skor kembali turun setiap ada perubahan |
Kebutuhan bisnis lain | Konten dan fitur masih sesuai | Website juga perlu fitur atau struktur baru |
Apakah revamp selalu menyelesaikan masalah? Tidak.
Website baru yang dibangun tanpa memperhatikan kinerja bisa sama lambatnya. Yang menentukan adalah apakah kinerja dijadikan syarat sejak perencanaan, bukan dikejar setelah website terbit. Pertimbangan lengkapnya bisa dilihat di layanan Website Revamp.
Pastikan Website Anda Memenuhi Standar Core Web Vitals
Kecepatan website ideal saat ini tidak diukur dari satu angka detik, melainkan dari tiga metrik Core Web Vitals. Patokan "baik" adalah LCP 2,5 detik atau kurang, INP 200 milidetik atau kurang, dan CLS 0,1 atau kurang, pada persentil ke-75 kunjungan nyata.
Langkah pertama yang paling realistis adalah mengecek halaman terpenting Anda dan membaca data pengguna nyata. Setelah itu, catat metrik mana yang gagal.
Dari situ, Anda bisa menilai apakah cukup dioptimasi atau perlu perubahan yang lebih mendasar.
Ingin tahu posisi website Anda terhadap ambang Core Web Vitals dan apa penyebabnya? Hubungi tim Grapiku untuk memetakan prioritas perbaikannya, atau pelajari layanan Website Revamp jika masalahnya ada di fondasi website.
- Apakah skor PageSpeed Insights 100 wajib dicapai?
- Tidak. Skor kinerja di PageSpeed Insights adalah hasil simulasi lab, sedangkan penilaian Core Web Vitals memakai data pengguna nyata. Website bisa lolos Core Web Vitals tanpa skor lab 100. Fokuskan perbaikan pada metrik yang gagal di data lapangan, terutama di halaman yang penting bagi bisnis.
- Kenapa hasil kecepatan di ponsel jauh lebih buruk daripada di desktop?
- Ponsel umumnya memiliki prosesor lebih lemah dan koneksi yang kurang stabil dibanding komputer kantor. Halaman dengan gambar besar atau banyak skrip terasa jauh lebih berat di ponsel. Karena itu, Core Web Vitals diukur terpisah untuk ponsel dan desktop, dan hasil ponsel layak diprioritaskan.
- Seberapa sering kecepatan website perlu dicek?
- Untuk sebagian besar website perusahaan, pengecekan bulanan sudah memadai. Lakukan pengecekan tambahan setelah ada perubahan besar, seperti pemasangan plugin baru, pergantian tema, atau penambahan banner dan skrip pelacak. Data lapangan Core Web Vitals memerlukan waktu untuk terkumpul, jadi hasil perbaikan tidak selalu langsung terlihat.



