Core Web Vitals 2026: Cara Mempercepat Website untuk SEO

Pernah membuka sebuah website, lalu halaman putih cukup lama sebelum kontennya muncul? Atau lebih menyebalkan lagi: kamu mau menekan tombol “Beli Sekarang”, tetapi tiba-tiba layout bergeser dan yang tertekan malah tombol lain. Masalah seperti ini bukan cuma bikin pengguna kesal. Google juga memperhatikan bagaimana pengalaman nyata pengguna ketika membuka dan berinteraksi dengan sebuah halaman melalui metrik yang disebut Core Web Vitals. Di 2026, Core Web Vitals masih terdiri dari tiga metrik utama: Largest Contentful Paint (LCP) untuk kecepatan loading konten utama, Interaction to Next Paint (INP) untuk responsivitas interaksi, serta Cumulative Layout Shift (CLS) untuk stabilitas visual. Google merekomendasikan LCP maksimal 2,5 detik, INP maksimal 200 milidetik, dan CLS maksimal 0,1 untuk pengalaman yang dikategorikan baik. Tapi apakah Core Web Vitals 2026 berarti website yang punya skor paling tinggi pasti ranking nomor satu? Nggak sesederhana itu. Konten, relevansi, backlink, search intent, dan berbagai sinyal lain tetap berperan. Google sendiri menjelaskan bahwa Core Web Vitals merupakan bagian dari aspek page experience yang selaras dengan apa yang ingin dihargai sistem ranking inti Google, bukan satu-satunya faktor ranking. Jadi tujuan optimasi seharusnya bukan sekadar mengejar warna hijau. Tujuannya adalah membuat website terasa cepat, responsif, stabil, dan nyaman digunakan. Mari kita bahas caranya.

 

Apa Itu Core Web Vitals 2026?

Core Web Vitals adalah sekumpulan metrik yang dibuat untuk mengukur pengalaman pengguna nyata ketika membuka website.

Bukan cuma soal berapa cepat server mengirim HTML.

Google mencoba melihat tiga hal yang lebih dekat dengan apa yang dirasakan manusia:

Apakah konten utama cepat terlihat?

Apakah website cepat merespons ketika disentuh atau diklik?

Apakah tampilannya tetap stabil saat loading?

Itulah kenapa tiga metriknya sekarang adalah LCP, INP, dan CLS.

Google juga menilai performa menggunakan persentil ke-75 dari kunjungan pengguna. Secara sederhana, sebuah halaman dianggap memiliki performa baik untuk suatu metrik jika setidaknya sekitar 75% pengalaman pengguna berada dalam ambang “good”.

Jadi jangan hanya melakukan satu tes dari laptop cepat dengan Wi-Fi kantor lalu berkata:

“Website saya cepat kok.”

Pengguna nyata mungkin memakai smartphone entry-level.

Jaringannya bisa lambat.

Lokasinya jauh dari server.

Perangkatnya juga sibuk menjalankan banyak aplikasi.

Itulah kenapa field data sangat penting.

Core Web Vitals 2026: Mengenal LCP, INP, dan CLS

Sebelum memperbaiki performa, kita perlu tahu apa yang sebenarnya diukur.

LCP – Largest Contentful Paint

LCP mengukur waktu sampai elemen konten terbesar yang terlihat pada viewport selesai dirender.

Biasanya elemen tersebut berupa:

• hero image;
• banner besar;
• heading utama;
• gambar produk;
• blok teks besar.

Target yang direkomendasikan Google adalah 2,5 detik atau kurang. LCP di atas 4 detik sudah masuk kategori buruk.

Jadi kalau homepage punya banner besar 6 MB dan baru muncul setelah lima detik, jangan heran kalau LCP bermasalah.

INP – Interaction to Next Paint

INP mengukur seberapa responsif halaman terhadap interaksi pengguna.

Misalnya pengguna:

klik menu;

tekan tombol;

pilih dropdown;

membuka modal;

menekan add to cart.

Google merekomendasikan INP 200 milidetik atau kurang, sedangkan lebih dari 500 milidetik masuk kategori buruk.

Kalau pengguna klik tombol lalu halaman terasa “diam” setengah detik sebelum bereaksi, INP bisa menjadi masalah.

CLS – Cumulative Layout Shift

CLS mengukur seberapa banyak elemen halaman berpindah secara tidak terduga ketika website sedang digunakan.

Pernah mau klik artikel, tetapi iklan tiba-tiba muncul dan mendorong konten ke bawah?

Nah, itu contoh layout shift.

Target CLS yang baik adalah 0,1 atau kurang, sementara nilai di atas 0,25 dianggap buruk.

Apakah Core Web Vitals Berpengaruh ke SEO?

Ya, tetapi jangan membesar-besarkannya.

Google secara resmi merekomendasikan pemilik website mencapai Core Web Vitals yang baik agar sukses di Search sekaligus memberikan pengalaman pengguna yang baik. Core Web Vitals merupakan bagian dari aspek page experience yang selaras dengan apa yang ingin dihargai sistem ranking Google.

Tetapi Google tidak mengatakan:

“LCP 2 detik otomatis ranking 1.”

Bayangkan ada dua artikel.

Artikel A sangat cepat tetapi isinya dangkal.

Artikel B sedikit lebih lambat tetapi benar-benar menjawab pertanyaan pengguna dengan lengkap, terpercaya, dan relevan.

Kecepatan tetap penting.

Tetapi SEO bukan balapan PageSpeed.

Perspektif yang menurut saya lebih sehat adalah:

Core Web Vitals membantu menghilangkan hambatan setelah Google dan pengguna menemukan kontenmu.

Konten membuat orang datang.

Performance membantu mereka bertahan.

Cara Mengecek Core Web Vitals Website

Sebelum optimasi, jangan menebak.

Ukur dulu.

Ada beberapa tool yang bisa digunakan.

Google PageSpeed Insights

Ini biasanya titik awal paling mudah.

Masukkan URL.

Kemudian kamu bisa melihat performa mobile dan desktop, termasuk Core Web Vitals serta berbagai peluang optimasi.

PageSpeed Insights juga bisa menampilkan data pengalaman pengguna nyata jika URL atau origin memiliki data Chrome UX Report yang cukup.

Google Search Console

Buka laporan:

Experience → Core Web Vitals

Search Console membantu melihat kelompok URL yang mengalami masalah.

Misalnya:

“LCP issue: longer than 2.5s.”

Ini berguna karena kamu tidak harus memeriksa setiap halaman satu per satu.

Google sendiri menyarankan penggunaan laporan Core Web Vitals di Search Console untuk memantau performa halaman.

Chrome DevTools

Kalau kamu developer, DevTools jauh lebih detail.

Kamu bisa menganalisis:

network;

JavaScript execution;

layout;

rendering;

LCP element;

long task.

Chrome 152 pada Agustus 2026 bahkan menambahkan peningkatan pada Performance Live Metrics, termasuk Core Web Vitals untuk soft navigation.

Jadi kalau PageSpeed hanya mengatakan “website lambat”, DevTools membantu mencari kenapa.

Cara Mempercepat Website untuk SEO dengan Memperbaiki LCP

LCP sering menjadi masalah paling mudah terlihat.

Penyebab paling umum biasanya hero image terlalu besar atau resource utama terlambat dimuat.

Misalnya homepage punya gambar:

hero-homepage-final-v7.png

Ukuran: 7,8 MB.

Resolusi: 5000 × 3000 pixel.

Ditampilkan di layar HP hanya selebar 400 pixel.

Itu pemborosan.

Langkah pertama:

optimalkan gambar.

Gunakan format modern seperti WebP atau AVIF jika sesuai.

Resize berdasarkan kebutuhan.

Kompres.

Jangan upload file kamera mentah langsung ke website.

Kamu juga harus memperhatikan prioritas loading.

Kalau hero image adalah elemen LCP, jangan malah memasangnya sebagai lazy-loaded image.

Browser harus tahu bahwa resource tersebut penting.

Selain gambar, LCP juga bisa lambat karena:

• TTFB tinggi;
• CSS blocking;
• font terlambat;
• JavaScript berat;
• CDN buruk;
• server lambat.

Jadi jangan otomatis menyalahkan gambar.

Gunakan data untuk mencari bottleneck sebenarnya.

Optimalkan Server dan TTFB

Website tidak bisa terasa cepat kalau server terlalu lama menjawab.

Misalnya pengguna membuka halaman.

Browser meminta HTML.

Server membutuhkan tiga detik hanya untuk menghasilkan respons.

Belum ada gambar.

Belum ada CSS.

Belum ada JavaScript.

Sudah tiga detik hilang.

Beberapa cara memperbaikinya:

• gunakan hosting yang sesuai;
• aktifkan page caching;
• optimalkan database;
• gunakan object cache;
• manfaatkan CDN;
• kurangi query berat;
• gunakan full-page cache untuk halaman yang memungkinkan.

Untuk WordPress, caching bisa memberikan perubahan besar.

Untuk Laravel atau framework custom, cek query database, middleware, API, dan proses backend yang terjadi sebelum respons dikirim.

Kadang developer sibuk mengoptimasi CSS 20 KB sementara query database membutuhkan dua detik.

Fokus dulu pada masalah terbesar.

Core Web Vitals 2026: Cara Memperbaiki INP

Website mungkin terlihat cepat.

Tetapi setelah tampil, tombolnya lambat.

Itulah masalah INP.

Penyebab utamanya sering berkaitan dengan pekerjaan berat di main thread, terutama JavaScript.

Bayangkan saat pengguna klik tombol menu.

Browser sebenarnya ingin langsung merespons.

Tetapi JavaScript sedang sibuk menjalankan pekerjaan 600 milidetik.

Klik pengguna harus menunggu.

Hasilnya terasa lag.

Untuk memperbaiki INP:

• kurangi JavaScript yang tidak perlu;
• pecah long tasks;
• lakukan code splitting;
• hindari event handler berat;
• lazy-load fitur sekunder;
• optimalkan framework hydration;
• kurangi third-party script;
• gunakan web worker jika memang cocok.

Jangan lupa third-party script.

Chat widget.

Analytics.

Heatmap.

Popup.

Ads.

Tracking pixel.

Satu per satu mungkin kecil.

Digabungkan bisa berat.

Coba audit:

Kalau script ini dihapus, apakah bisnis benar-benar kehilangan sesuatu?

Kalau jawabannya tidak, hapus.

Jangan Kirim JavaScript yang Tidak Digunakan

Website modern sering punya satu masalah:

browser harus download banyak kode yang sebenarnya tidak dibutuhkan pengguna.

Misalnya homepage cuma menampilkan informasi perusahaan.

Tapi browser ikut mengunduh JavaScript:

calendar;

chart;

rich text editor;

admin component;

carousel library;

animation engine.

Padahal tidak digunakan.

Ini sering terjadi pada aplikasi berbasis framework atau theme besar.

Solusinya bisa berupa:

tree shaking;

dynamic import;

route-based splitting;

component lazy loading.

Intinya:

kirim hanya kode yang dibutuhkan halaman saat itu.

Semakin sedikit JavaScript, semakin sedikit pekerjaan yang harus dilakukan browser.

Dan perangkat low-end akan sangat merasakan perbedaannya.

Cara Memperbaiki CLS agar Layout Tidak Loncat-Loncat

CLS sering terasa sepele sampai kita mengalaminya sendiri.

Misalnya kamu sedang membaca artikel.

Tiba-tiba banner iklan muncul.

Seluruh paragraf bergeser.

Atau kamu mau klik:

“Beli.”

Tiba-tiba gambar selesai load dan tombol berpindah.

Kesal, kan?

Penyebab paling umum biasanya elemen tidak mempunyai ukuran yang sudah diketahui browser.

Misalnya:

<img src="produk.jpg">

Browser belum tahu gambar akan setinggi apa.

Ketika gambar selesai loading, halaman harus menggeser elemen lain.

Lebih baik beri dimensi:

width

dan

height

atau gunakan aspect ratio yang jelas.

Hal serupa berlaku untuk:

• iklan;
• iframe;
• embed video;
• banner;
• popup;
• widget pihak ketiga.

Siapkan ruang sebelum konten muncul.

Jangan biarkan elemen datang tiba-tiba dan mendorong seluruh halaman.

Optimasi Font untuk Core Web Vitals

Font custom bisa membuat website terlihat bagus.

Tapi bisa juga memperlambat loading.

Misalnya website memuat:

Roboto Regular.

Roboto Medium.

Roboto Bold.

Roboto Italic.

Poppins Regular.

Poppins Medium.

Poppins Bold.

Belum konten tampil, browser sudah sibuk mengambil banyak file font.

Gunakan seperlunya.

Beberapa strategi:

• self-host font jika masuk akal;
• preload font kritis;
• gunakan font-display;
• kurangi jumlah weight;
• gunakan subset karakter;
• pertimbangkan system font.

Untuk website company profile sederhana, kamu mungkin tidak membutuhkan tujuh weight font.

Desain tetap bisa bagus dengan dua atau tiga.

Lebih sedikit resource.

Lebih cepat.

Lazy Loading Itu Bagus, Tapi Jangan Digunakan untuk Semua Gambar

Lazy loading adalah teknik menunda loading resource sampai mendekati viewport.

Sangat berguna untuk halaman panjang.

Misalnya artikel memiliki 20 gambar.

Tidak perlu memuat semuanya saat pengguna baru melihat bagian atas.

Tetapi ada kesalahan yang sering terjadi:

hero image juga di-lazy load.

Padahal hero image mungkin justru elemen LCP.

Browser akhirnya menunda resource yang seharusnya diprioritaskan.

Gunakan lazy loading untuk gambar below the fold.

Untuk elemen kritis di atas halaman, prioritaskan.

Performance optimization bukan soal memakai sebanyak mungkin teknik.

Tapi menggunakan teknik pada tempat yang tepat.

Gunakan CDN Kalau Pengguna Tersebar

Bayangkan server berada di Jakarta.

Pengguna di Jakarta mungkin mendapat respons cepat.

Tetapi pengguna di Eropa harus mengambil file dari jarak jauh.

CDN atau Content Delivery Network membantu menyimpan copy resource di berbagai lokasi edge.

File statis seperti:

gambar;

CSS;

JavaScript;

font;

bisa disajikan dari lokasi yang lebih dekat dengan pengguna.

Untuk bisnis yang targetnya hanya satu kota, dampaknya mungkin lebih kecil.

Untuk website nasional atau internasional, CDN bisa sangat membantu.

Namun jangan menganggap CDN menyelesaikan semua masalah.

Kalau backend menghasilkan HTML selama lima detik, CDN tidak otomatis memperbaiki aplikasi yang buruk.

Contoh Kasus: Website Ecommerce Lambat Padahal Hosting Mahal

Bayangkan sebuah toko online.

Hosting-nya mahal.

Server punya RAM besar.

CPU juga tinggi.

Tetapi PageSpeed mobile hanya 42.

Pemilik bisnis langsung berpikir:

“Upgrade server lagi.”

Setelah diperiksa, ternyata masalahnya:

hero banner 5 MB;

enam font custom;

chat widget;

Facebook Pixel;

TikTok Pixel;

Google Tag Manager;

popup script;

carousel library;

empat plugin analytics;

JavaScript theme besar.

Server bukan bottleneck utama.

Setelah gambar dikompres, script tidak perlu dihapus, font dikurangi, dan JavaScript ditunda, performa meningkat jauh tanpa mengganti server.

Ini contoh yang sering terjadi.

Website lambat tidak selalu berarti hosting buruk.

Kadang halaman sendiri terlalu berat.

Karena itu audit sebelum membeli resource tambahan.

Mobile Harus Jadi Prioritas

Tes website dari laptop developer sering menipu.

Laptop:

RAM 32 GB.

CPU cepat.

Wi-Fi 300 Mbps.

Website terasa instant.

Pengguna nyata?

HP Android kelas menengah.

Paket data.

Banyak aplikasi aktif.

CPU jauh lebih lambat.

Itulah kenapa optimasi mobile penting.

Core Web Vitals menggunakan pengalaman pengguna nyata dan hasilnya dapat berbeda antara desktop serta mobile. Google merekomendasikan pengukuran pada persentil ke-75 dan memisahkan pengalaman berdasarkan tipe perangkat.

Jadi kalau desktop hijau tetapi mobile merah, jangan berkata:

“Yang penting desktop bagus.”

Pengguna bisnis kamu mungkin mayoritas justru datang lewat HP.

Fakta Menarik: Baru Sekitar 55,7% Origin yang Lulus Core Web Vitals

Data Chrome UX Report terbaru yang tersedia untuk Juli 2026 menunjukkan sekitar 55,7% origin memiliki Core Web Vitals yang dikategorikan baik secara keseluruhan.

Untuk masing-masing metrik:

• sekitar 68,3% origin memiliki LCP baik;
• sekitar 81,6% memiliki CLS baik;
• sekitar 85,7% memiliki INP baik.

Dataset Juli 2026 tersebut mencakup lebih dari 18 juta origin.

Angka ini menarik.

Artinya lebih dari empat dari sepuluh origin yang tercatat masih belum lulus seluruh Core Web Vitals secara bersamaan.

Jadi kalau website kamu belum semuanya hijau, kamu tidak sendirian.

Tetapi justru itu peluang.

Website yang lebih cepat dan nyaman bisa punya keunggulan pengalaman pengguna dibanding kompetitor yang masih berat.

Jangan Terobsesi dengan Skor PageSpeed 100

Ini mungkin bagian terpenting.

Skor 100 terasa memuaskan.

Screenshot-nya bagus.

Bisa dipamerkan.

Tetapi jangan merusak website hanya demi angka.

Misalnya kamu menghapus semua analytics hanya supaya skor meningkat.

Padahal marketing membutuhkan data tersebut.

Atau menghilangkan fitur live chat yang benar-benar menghasilkan leads.

Itu bukan optimasi.

Itu memindahkan masalah.

Fokus pada:

LCP.

INP.

CLS.

Pengalaman pengguna nyata.

Conversion.

Business impact.

Kalau PageSpeed score 89 tetapi Core Web Vitals bagus dan conversion naik, itu jauh lebih berarti daripada skor 100 dengan website yang tidak berguna.

Field Data vs Lab Data: Jangan Sampai Tertukar

Ini juga sering membingungkan.

Kamu membuka PageSpeed Insights.

Lab test merah.

Tetapi Core Web Vitals Assessment hijau.

Kok bisa?

Karena datanya berbeda.

Lab data adalah simulasi dalam kondisi tertentu.

Berguna untuk debugging.

Field data berasal dari pengalaman pengguna nyata melalui Chrome UX Report.

Google menggunakan data pengguna nyata untuk Core Web Vitals dan merekomendasikan evaluasi pada persentil ke-75.

Keduanya penting.

Gunakan field data untuk memahami pengalaman sebenarnya.

Gunakan lab data untuk mencari masalah dan menguji perbaikan.

Jangan memilih salah satu saja.

Checklist Cara Mempercepat Website untuk SEO

Kalau ingin mulai optimasi sekarang, gunakan checklist berikut:

1. Tes website di PageSpeed Insights.
2. Cek laporan Core Web Vitals Search Console.
3. Identifikasi elemen LCP.
4. Kompres hero image.
5. Gunakan WebP atau AVIF jika sesuai.
6. Optimalkan TTFB.
7. Aktifkan caching.
8. Kurangi JavaScript tidak terpakai.
9. Audit third-party scripts.
10. Pecah long tasks.
11. Tentukan ukuran gambar dan iframe.
12. Kurangi jumlah font.
13. Lazy-load gambar below the fold.
14. Gunakan CDN jika diperlukan.
15. Tes ulang di perangkat mobile nyata.

Jangan mencoba memperbaiki semuanya sekaligus.

Cari bottleneck terbesar.

Kalau LCP lima detik, mulai dari LCP.

Kalau LCP sudah 1,8 detik tetapi INP 600 ms, fokus ke JavaScript.

Optimasi berbasis data jauh lebih efektif daripada checklist buta.

Perspektif Baru: Kecepatan Website Bukan Proyek Sekali Selesai

Ada satu kesalahan umum.

Developer melakukan optimasi.

PageSpeed hijau.

Project dinyatakan selesai.

Enam bulan kemudian:

marketing memasang chat widget;

tiga tracking pixel;

popup;

video autoplay;

font baru;

plugin baru.

Website lambat lagi.

Performance sebenarnya bukan pekerjaan satu kali.

Ia adalah budget.

Misalnya tim menetapkan aturan:

JavaScript halaman maksimal sekian KB.

Hero image maksimal 200 KB.

LCP harus di bawah 2,5 detik.

INP harus di bawah 200 ms.

Setiap fitur baru harus mengikuti budget tersebut.

Dengan cara ini, performa menjadi bagian dari proses development.

Bukan pekerjaan bersih-bersih setelah website telanjur berat.

Kesimpulan

Jadi, Core Web Vitals 2026 masih berfokus pada tiga metrik:

LCP untuk loading.

INP untuk responsivitas.

CLS untuk stabilitas visual.

Target Google tetap jelas: LCP maksimal 2,5 detik, INP maksimal 200 ms, dan CLS maksimal 0,1 untuk pengalaman yang dianggap baik.

Apakah memperbaiki Core Web Vitals bisa membantu SEO?

Ya, page experience tetap relevan dalam Search.

Tetapi jangan menganggapnya jalan pintas menuju ranking pertama.

Buat konten yang benar-benar relevan.

Bangun website yang mudah dirayapi.

Kemudian pastikan ketika pengguna akhirnya datang, mereka tidak disambut oleh loading lambat, tombol lag, dan layout yang lompat-lompat.

Kalau ingin mulai hari ini, lakukan satu hal sederhana:

Buka PageSpeed Insights dan tes tiga halaman terpenting website kamu: homepage, halaman produk/layanan utama, dan artikel dengan traffic paling tinggi.

Lihat LCP, INP, dan CLS.

Cari metrik paling buruk.

Perbaiki satu masalah terbesar terlebih dahulu.

Karena website cepat bukan cuma membuat Google lebih senang.

Website cepat membuat manusia lebih sedikit punya alasan untuk menutup halaman dan pergi ke kompetitor.