Core Web Vitals 2026: Kecepatan Situs vs Peringkat Google & AI

Di bulan Maret 2026, Rani Kusuma, pemilik toko sepatu online Sepatu Anggun di Bandung, membuka laporan Google Analytics dan menemukan angka yang membuatnya duduk lebih tegak: rata-rata waktu muat halaman produk unggulannya adalah 6,8 detik, dan bounce rate untuk trafik dari iklan Google Ads mencapai 68%. Selama tiga bulan terakhir, ia sudah menghabiskan Rp 42 juta untuk iklan, tapi konversi hanya 1,1%—jauh di bawah rata-rata industri e-commerce fesyen yang berkisar 2,5-3%. Ketika tim marketingnya menghitung ulang, mereka memperkirakan toko itu kehilangan sekitar Rp 180 juta pendapatan potensial per bulan hanya karena pengunjung menutup tab sebelum halaman produk selesai dimuat.

Yang lebih menyakitkan datang dua minggu kemudian. Seorang calon pelanggan bertanya ke ChatGPT, "rekomendasi toko sepatu kulit lokal terbaik di Indonesia dengan pengiriman cepat," dan jawaban yang muncul menyebutkan tiga kompetitor—termasuk LangkahKita, pesaing langsung Rani—lengkap dengan tautan dan alasan kenapa mereka direkomendasikan. Sepatu Anggun sama sekali tidak disebut, padahal produknya setara bahkan lebih baik dari segi kualitas. Saat Rani menelusuri lebih jauh, ia menemukan bahwa crawler AI kemungkinan besar gagal memuat halaman produknya dengan sempurna dalam batas waktu yang mereka alokasikan, karena situs itu memuat lebih dari 40 skrip pihak ketiga, gambar produk berukuran rata-rata 3,2 MB tanpa kompresi, dan builder halaman yang ia pakai menyuntikkan CSS serta JavaScript yang jauh lebih besar dari yang sebenarnya dibutuhkan.

Apa yang Sebenarnya Diukur oleh Core Web Vitals

Core Web Vitals adalah tiga metrik inti yang dipakai Google untuk menilai pengalaman nyata pengguna di sebuah halaman, dan sejak 2024 metrik ini juga menjadi proksi tak resmi yang dipakai banyak sistem AI untuk menilai apakah sebuah halaman "layak" diproses lebih lanjut.

Largest Contentful Paint (LCP) mengukur berapa lama elemen konten terbesar yang terlihat—biasanya gambar hero, judul besar, atau video—selesai dirender di layar. Google menganggap LCP "baik" jika terjadi dalam 2,5 detik atau kurang sejak halaman mulai dimuat; 2,5-4 detik dikategorikan "perlu perbaikan"; dan di atas 4 detik dikategorikan "buruk." LCP pada dasarnya menjawab pertanyaan paling mendasar pengunjung: apakah situs ini benar-benar memuat sesuatu yang bisa saya lihat, atau saya harus menunggu?

Interaction to Next Paint (INP) menggantikan First Input Delay sebagai metrik interaktivitas resmi sejak Maret 2024. INP mengukur responsivitas keseluruhan halaman terhadap interaksi pengguna—klik tombol, ketuk menu, isi formulir—dari seluruh siklus kunjungan, bukan cuma interaksi pertama. Ambang "baik" adalah 200 milidetik atau kurang; 200-500 md "perlu perbaikan"; di atas 500 md "buruk." Situs dengan INP buruk terasa lag—tombol ditekan tapi responsnya baru muncul setengah detik kemudian, yang di dunia nyata sering ditafsirkan pengguna sebagai situs rusak, bukan sekadar lambat.

Cumulative Layout Shift (CLS) mengukur seberapa banyak elemen di halaman "meloncat" posisinya secara tidak terduga saat halaman masih memuat—kasus klasiknya adalah pengguna hendak menekan tombol "Tambah ke Keranjang" tapi tiba-tiba sebuah banner iklan muncul dan tombol itu bergeser, sehingga yang tertekan malah link lain. Skor CLS "baik" adalah di bawah 0,1; 0,1-0,25 "perlu perbaikan"; di atas 0,25 "buruk."

Yang jarang dibahas: crawler AI—baik milik Google untuk AI Overviews, OpenAI untuk penjelajahan ChatGPT, maupun Perplexity—beroperasi dengan crawl budget dan batas waktu per halaman yang jauh lebih ketat dibanding crawler pencarian tradisional, karena biaya komputasi untuk memproses dan meringkas satu halaman jauh lebih mahal daripada sekadar mengindeksnya. Ketika sebuah halaman butuh lebih dari beberapa detik untuk merender konten utamanya, atau bergantung sepenuhnya pada JavaScript sisi klien yang berat untuk menampilkan teks, banyak crawler AI akan melewatkannya sama sekali, atau hanya berhasil menangkap versi halaman yang kosong dan mentah. Praktis, ini berarti kecepatan situs sekarang bukan cuma soal peringkat di kotak biru Google, melainkan soal apakah bisnis Anda ada atau tidak ada dalam jawaban yang dihasilkan AI.

Biaya Nyata dari Website yang Lambat

• Bounce rate melonjak tajam untuk setiap detik tambahan waktu muat — riset Google bersama SOASTA menemukan bahwa begitu waktu muat halaman melewati 3 detik di perangkat mobile, kemungkinan pengunjung langsung pergi naik hingga 32%, dan riset konversi yang banyak dikutip memperkirakan setiap tambahan 100 milidetik keterlambatan berpotensi menurunkan konversi sekitar 7%.
• Kehilangan posisi peringkat pencarian di Google — Core Web Vitals adalah bagian resmi dari sinyal Page Experience yang dipakai algoritma peringkat Google sejak 2021, dan Google terus memperbarui ambang batasnya (terakhir mengganti FID dengan INP pada Maret 2024); situs yang gagal memenuhi ambang "baik" secara konsisten kalah bersaing di halaman hasil pencarian melawan kompetitor yang skornya hijau.
• Dilewati crawler AI dan absen dari jawaban mesin AI — ChatGPT Search, Perplexity, dan Google AI Overviews semuanya bergantung pada crawler yang punya anggaran waktu ketat per halaman; halaman yang lambat dirender atau butuh eksekusi JavaScript ekstensif untuk menampilkan teks utamanya berisiko tidak pernah masuk ke basis pengetahuan yang dipakai AI untuk menjawab, artinya bisnis Anda kehilangan visibilitas di saluran pencarian yang tumbuh paling cepat saat ini.
• Anggaran iklan terbuang percuma — mendatangkan trafik berbayar ke halaman yang lambat sama saja membakar uang; jika 6 dari 10 pengunjung yang diklik dari iklan pergi sebelum halaman selesai dimuat, praktis setengah anggaran marketing digital tidak pernah punya kesempatan untuk berkonversi.
• Biaya infrastruktur lebih tinggi akibat kode yang tidak efisien — situs dengan bundle JavaScript membengkak, query database yang tidak dioptimalkan, dan aset yang tidak terkompresi butuh lebih banyak sumber daya server untuk melayani jumlah pengunjung yang sama, sehingga tagihan hosting dan CDN membengkak padahal performa yang dirasakan pengguna tetap buruk.

Apa yang Dibutuhkan Website yang Benar-Benar Cepat dan Ramah Crawler AI

• Gambar teroptimasi dan lazy-loaded dalam format modern (WebP/AVIF) — foto produk mentah dari kamera DSLR atau HP flagship bisa berukuran 4-8 MB; dikonversi ke WebP atau AVIF dengan kompresi yang tepat, ukurannya bisa turun 60-80% tanpa penurunan kualitas visual yang terlihat mata, dan lazy loading memastikan gambar di bagian bawah halaman baru diunduh saat pengguna benar-benar menggulir ke sana.
• JavaScript render-blocking diminimalkan — setiap skrip yang harus selesai dieksekusi sebelum browser bisa merender konten menunda LCP secara langsung. Kode yang tidak penting untuk tampilan awal—widget chat, tracking pihak ketiga, animasi dekoratif—sebaiknya dimuat secara asinkron atau ditunda setelah konten utama tampil.
• Server-side rendering (SSR) atau static site generation (SSG), bukan rendering client-side yang berat — situs yang seluruh kontennya baru muncul setelah JavaScript selesai dieksekusi di browser pengunjung menunda LCP secara signifikan dan sering gagal diparsing sempurna oleh crawler AI yang tidak selalu mengeksekusi JavaScript secara penuh. SSR atau SSG mengirim HTML yang sudah berisi konten jadi ke browser maupun crawler.
• CDN dengan edge caching — menyajikan aset statis seperti gambar, CSS, font, dan video dari server yang secara geografis dekat dengan pengunjung memangkas latensi jaringan secara drastis, terutama penting untuk bisnis dengan ambisi pasar internasional yang pengunjungnya tersebar lintas benua.
• HTML semantik yang bersih, bisa diparsing tanpa eksekusi JavaScript berat — tag heading, list, table, dan struktur konten yang jelas membuat baik mesin pencari maupun crawler AI bisa langsung memahami hierarki dan makna konten tanpa harus menebak lewat DOM yang dirender JavaScript.
• Lapisan structured data/schema markup yang ringan — markup Schema.org seperti Product, FAQ, Article, dan LocalBusiness memberi konteks eksplisit yang membantu AI Overviews dan mesin jawaban lain mengutip data Anda secara akurat, tanpa menambah beban rendering berarti karena berupa JSON-LD ringan di head dokumen.
• Monitoring performa berkelanjutan, bukan perbaikan sekali jalan — performa situs terdegradasi secara alami seiring waktu: tim marketing menambah tracking pixel baru, tim konten mengunggah gambar besar, developer menambah dependency baru. Tanpa pemantauan rutin lewat tool seperti PageSpeed Insights, Lighthouse CI, atau Chrome UX Report (CrUX), penurunan performa baru disadari setelah dampaknya terasa di angka konversi.

Website Builder/Template vs Performa Website Custom

Platform website builder dan template siap pakai—baik builder drag-and-drop populer maupun tema premium di marketplace—dirancang untuk fleksibilitas maksimum bagi ribuan kasus penggunaan berbeda, dan fleksibilitas itu punya harga: kode yang jauh lebih besar dari yang sebenarnya dibutuhkan satu bisnis spesifik. Satu tema bisa memuat CSS dan JavaScript untuk puluhan varian layout, animasi, dan plugin yang tidak pernah dipakai, tapi tetap diunduh browser setiap pengunjung. Ditambah plugin pihak ketiga untuk fitur seperti popup, live chat, review, dan analytics—yang masing-masing menambah request jaringan dan skrip yang harus dieksekusi—situs berbasis builder sering kali kesulitan keras menembus skor LCP di bawah 2,5 detik begitu jumlah halaman dan fitur bertambah, apalagi saat trafik naik dan server shared hosting kewalahan.

Website yang dibangun custom dari awal punya keunggulan struktural: setiap baris kode ada karena benar-benar dibutuhkan bisnis tersebut, arsitektur rendering seperti SSR atau SSG dipilih sejak awal sesuai kebutuhan, dan tidak ada beban warisan dari plugin yang tidak terpakai. Ini bukan berarti builder selalu buruk untuk semua kasus—untuk landing page sederhana atau bisnis yang baru mulai, builder bisa masuk akal dari sisi biaya awal. Tapi begitu bisnis serius soal konversi, SEO, dan visibilitas di jawaban AI, terutama dengan katalog produk besar atau traffic tinggi, investasi ke arsitektur custom biasanya terbayar lewat performa yang jauh lebih konsisten dan bisa diskalakan.

Kisaran Biaya dan Waktu Pengerjaan

Untuk pasar Indonesia, proyek rebuild website atau webapp custom yang dioptimalkan performanya secara serius—termasuk audit Core Web Vitals, restrukturisasi arsitektur rendering, optimasi aset, dan implementasi CDN—umumnya berkisar Rp 35 juta untuk situs company profile atau landing page dengan beberapa halaman, hingga Rp 200 juta atau lebih untuk platform e-commerce/webapp dengan katalog besar, sistem pembayaran, dan integrasi API kompleks. Timeline pengerjaan biasanya 6 minggu untuk proyek skala kecil-menengah, sampai 4 bulan untuk sistem besar dengan banyak halaman, integrasi pihak ketiga, dan proses migrasi data. Kisaran ini sudah mencakup pengujian performa berulang, bukan cuma sekali saat serah terima, karena angka Core Web Vitals yang stabil butuh iterasi, bukan tebakan sekali jadi.

Studi Kasus: JayaMart Elektronik

JayaMart Elektronik, peritel elektronik online dengan katalog lebih dari 3.000 produk dan lima cabang fisik di Jawa, mendatangi AFSS pada akhir 2025 dengan keluhan familiar: skor PageSpeed Insights merah di semua halaman produk, LCP rata-rata 5,9 detik di mobile, dan bounce rate 61%. Setelah audit menyeluruh, tim menemukan penyebab utamanya adalah tema WooCommerce bawaan yang dimodifikasi berlapis-lapis selama lima tahun, 34 plugin aktif yang banyak di antaranya tidak lagi dipakai fungsinya, dan gambar produk yang diunggah langsung dari supplier tanpa kompresi.

Setelah proses rebuild ke arsitektur custom dengan Next.js—SSR untuk halaman produk, static generation untuk halaman kategori—migrasi gambar ke format AVIF dengan lazy loading, dan implementasi CDN edge caching, hasil setelah delapan minggu sangat signifikan: LCP turun dari 5,9 detik menjadi 1,8 detik, bounce rate turun dari 61% menjadi 34%, dan trafik organik naik 47% dalam tiga bulan setelah peluncuran karena peringkat halaman kategori utama membaik signifikan di Google. Yang paling membuat tim JayaMart senang: dua bulan setelah peluncuran, tim marketing menemukan produk mereka disebut lengkap dengan harga dan link saat menguji pertanyaan "rekomendasi kulkas 2 pintu hemat listrik" di Google AI Overview—sesuatu yang sebelumnya tidak pernah terjadi.

Metrik Kunci yang Perlu Dipantau Setelah Implementasi

• Skor Core Web Vitals via PageSpeed Insights dan Chrome UX Report (CrUX) — pantau data lapangan dari pengguna nyata, bukan cuma skor lab, karena itu yang benar-benar dipakai Google untuk menilai Page Experience.
• Bounce rate dan waktu tinggal di halaman — turunnya bounce rate biasanya adalah sinyal paling cepat terlihat setelah optimasi performa berhasil.
• Trafik organik dan trafik rujukan dari AI — pantau sumber trafik dari domain seperti chat.openai.com, perplexity.ai, dan gemini.google.com di Google Analytics untuk melihat apakah situs mulai dikutip mesin AI.
• Tingkat konversi — ukuran akhir yang paling menentukan apakah investasi performa benar-benar berdampak ke pendapatan.
• Waktu respons server (Time to First Byte/TTFB) — indikator awal kesehatan backend dan hosting, karena TTFB yang lambat membatasi seberapa cepat LCP bisa dicapai apa pun optimasi front-end yang dilakukan.

Tantangan Implementasi dan Cara Mengatasinya

Tantangan paling umum adalah skrip pihak ketiga warisan—tracking pixel dari kampanye iklan lama, widget chat dari vendor yang sudah tidak dipakai, plugin analitik ganda yang terpasang bertahun-tahun tanpa pernah diaudit ulang. Solusinya bukan menghapus semua secara membabi buta, tapi melakukan audit menyeluruh terhadap setiap skrip: yang benar-benar dipakai tim marketing dimuat secara asinkron atau ditunda, yang sudah tidak relevan dihapus sepenuhnya, dan sisanya dikonsolidasikan lewat tag manager yang dikelola dengan disiplin.

Tantangan kedua datang dari tim konten sendiri: begitu situs baru diluncurkan dengan performa bagus, tim marketing atau konten sering tanpa sadar mengunggah gambar beresolusi tinggi langsung dari kamera atau software desain tanpa kompresi, perlahan mengembalikan situs ke kondisi lambat semula. Solusinya adalah membangun pipeline optimasi gambar otomatis di sisi server—resize dan konversi format otomatis saat upload—sehingga tim konten tidak perlu jadi ahli teknis untuk tetap menjaga performa.

Tantangan ketiga adalah menyeimbangkan fitur interaktif yang kaya—kalkulator harga, konfigurator produk 3D, chat AI, personalisasi real-time—dengan kecepatan. Solusi yang biasa dipakai adalah code splitting, yaitu memuat kode fitur interaktif hanya saat benar-benar dibutuhkan, bukan di muatan awal halaman, dan progressive enhancement, di mana konten inti selalu tersedia cepat sementara fitur interaktif menyusul dimuat setelahnya tanpa mengganggu LCP awal.

Kecepatan situs pada 2026 bukan lagi sekadar detail teknis yang bisa didiskusikan nanti—ini adalah pintu gerbang apakah bisnis Anda terlihat sama sekali, baik di halaman hasil pencarian Google maupun di jawaban yang dihasilkan ChatGPT, Perplexity, dan Gemini. Langkah pertama yang bisa Anda lakukan hari ini adalah menguji skor Core Web Vitals situs Anda saat ini lewat PageSpeed Insights, lalu bandingkan dengan kompetitor utama Anda. Jika hasilnya mengkhawatirkan, tim AFSS siap membantu—cek harga untuk gambaran investasi yang dibutuhkan, atau langsung ajukan-proyek untuk audit performa dan diskusi kebutuhan spesifik bisnis Anda.