Core Web Vitals 2026: ambang batas dan yang berubah
Metriknya tidak berubah tahun ini. Banyak perkakas di sekitarnya yang berubah. Ini yang benar-benar berlaku sekarang.
Tiga metrik, dan tetap tiga yang sama sejak 2024. Largest Contentful Paint sebaiknya selesai dalam 2,5 detik atau kurang, Interaction to Next Paint dalam 200 milidetik atau kurang, dan Cumulative Layout Shift di angka 0,1 atau kurang. Masing-masing dinilai pada persentil ke-75 dari pemuatan halaman nyata, dipisah antara seluler dan desktop.
Berapa ambang batas Core Web Vitals pada 2026?
Angka-angka ini langsung dari halaman metrik di web.dev, tempat Google menerbitkan definisinya. Semuanya dinilai pada persentil ke-75 dari pemuatan halaman, jadi Anda lulus ketika tiga perempat pengunjung nyata mendapat hasil yang baik, bukan ketika laptop Anda yang mendapatkannya.
| Metrik | Yang diukur | Baik | Perlu perbaikan | Buruk |
|---|---|---|---|---|
| LCP | Pemuatan, saat elemen terbesar yang terlihat selesai dirender | 2,5 detik atau kurang | 2,5 sampai 4,0 detik | Lebih dari 4,0 detik |
| INP | Responsivitas di seluruh interaksi pada halaman | 200 ms atau kurang | Lebih dari 200 ms hingga 500 ms | Lebih dari 500 ms |
| CLS | Stabilitas visual, ledakan pergeseran tak terduga yang terburuk | 0,1 atau kurang | Lebih dari 0,1 hingga 0,25 | Lebih dari 0,25 |
Apakah Core Web Vitals benar-benar berubah pada 2026?
Tidak. Bukan set metriknya, bukan pula satu ambang batas pun. Perubahan struktural terakhir terjadi pada 12 Maret 2024, ketika Interaction to Next Paint menjadi Core Web Vital yang stabil dan First Input Delay dipensiunkan, seperti diumumkan web.dev lewat tulisan INP becomes a Core Web Vital. Sejak itu setnya tetap tiga metrik stabil, tanpa ada pengganti eksperimental atau yang tertunda disebutkan. Aturan Google sendiri menyatakan Core Web Vitals yang stabil tidak akan berubah lebih dari sekali setahun, dan 2025 maupun 2026 berlalu tanpa satu perubahan pun.
Yang bergerak justru lapisan pengukurannya. Catatan rilis Chrome UX Report di Chrome for Developers mencatat bahwa subbagian gambar LCP dan jenis sumber daya LCP hadir di CrUX API pada Januari 2025, bahwa dimensi ECT dipensiunkan dari BigQuery pada rilis yang sama, dan bahwa CrUX Dashboard lama tidak lagi didukung pada akhir November 2025. Terpisah dari itu, pekerjaan soft navigations sampai ke Chrome 151, sehingga aplikasi satu halaman bisa mengaitkan LCP, INP, dan CLS ke tiap perubahan rute, bukan ke satu tampilan halaman yang tak berujung. Dokumentasinya tegas menyebut bahwa cara soft navigation akan dilaporkan di CrUX masih belum diputuskan, jadi hal itu belum memengaruhi angka Search Console Anda.
Kalau ada yang bilang metrik baru muncul tahun ini, tanyakan yang mana. Tidak ada.
Cara memperbaiki LCP yang lambat
Hampir semua LCP yang buruk sebenarnya masalah keterdeteksian. Panduan perbaikan utama di web.dev menempatkan tiga hal di urutan teratas: pastikan sumber daya LCP terlihat di sumber HTML alih-alih disisipkan oleh skrip, tandai dengan fetchpriority="high", dan pangkas Time to First Byte memakai CDN yang men-cache dokumennya sendiri. Setelah itu, kejar navigasi seketika lewat back and forward cache atau speculation rules, supaya halaman berikutnya sudah siap saat kliknya terjadi.
Cara memperbaiki INP yang tinggi
INP terpecah menjadi tiga bagian: input delay sebelum handler Anda berjalan, durasi pemrosesan handler itu, dan presentation delay sebelum frame berikutnya tergambar. Skor yang dilaporkan kira-kira interaksi terburuk pada halaman, dengan satu pencilan diabaikan tiap lima puluh interaksi. Perbaikan yang dianjurkan adalah sering menyerahkan kendali (yielding) supaya tugas panjang berhenti memblokir main thread, mengirim lebih sedikit JavaScript sejak awal, dan menjaga pembaruan render tetap kecil dengan DOM yang ringkas serta CSS containment. Audit tag manager Anda. Biasanya biangnya ada di sana.
Cara memperbaiki pergeseran tata letak
CLS melihat ledakan pergeseran yang terburuk, yang didefinisikan sebagai pergeseran berjarak kurang dari satu detik di dalam jendela paling lama lima detik. Tetapkan lebar dan tinggi eksplisit atau rasio aspek pada tiap gambar dan sematan, sediakan ruang untuk apa pun yang disisipkan belakangan seperti banner dan bilah persetujuan, jaga halaman tetap layak untuk back and forward cache, dan animasikan dengan transform alih-alih properti yang memaksa layout.
Di mana sebaiknya Core Web Vitals diukur?
Data lapangan lebih dulu, selalu. Alat lab berguna untuk menangkap regresi sebelum Anda rilis, dan web.dev terus terang bahwa alat itu bukan pengganti pengguna nyata di perangkat nyata. Chrome User Experience Report adalah dataset lapangannya. PageSpeed Insights dan laporan Core Web Vitals di Search Console sama-sama membacanya, sementara pustaka JavaScript web-vitals memberi angka Anda sendiri dengan jeda jauh lebih singkat ketimbang jendela bergulir 28 hari. Chrome DevTools dan Lighthouse mengurus sisi lab. Pakai keduanya, tetapi hanya data lapangan yang menentukan Anda lulus atau tidak.
Apakah Core Web Vitals masih memengaruhi peringkat Google?
Google Search Central masih mendokumentasikan Core Web Vitals sebagai bagian dari page experience, menyebutnya metrik yang mengukur pengalaman pengguna nyata dan menyatakannya selaras dengan apa yang ingin dihargai sistem peringkat intinya. Itu sengaja dibuat lebih lunak daripada faktor peringkat. Perlakukan sebagai penentu di antara halaman yang sebanding, dan sebagai hal yang jelas memengaruhi konversi, apa pun yang dilakukan Search. Logika yang sama berlaku untuk sisa fondasi teknis Anda, dan itulah yang diperiksa pemeriksa kesiapan AI kami.
Satu hal yang layak disampaikan kepada siapa pun yang mengejar skor sempurna: lulus ketiga ambang batas pada persentil ke-75 adalah garis finisnya. Tidak ada tingkat bonus di atasnya. Begitu semuanya hijau, satu jam berikutnya lebih berharga dipakai memastikan crawler bisa menjangkau halamannya sama sekali, dan itu pemeriksaan lima menit di robots.txt Anda.