Core Web Vitals: Kenapa Kecepatan Website Menentukan Konversi

Kecepatan website sering diperlakukan sebagai urusan selera teknis: enak kalau cepat, tetapi bukan prioritas. Padahal dampaknya sangat konkret. Setiap detik tambahan sebelum halaman terbaca menggeser sebagian pengunjung keluar — bukan karena mereka tidak tertarik, melainkan karena mereka tidak sempat melihat apa yang Anda tawarkan.

Core Web Vitals adalah cara mengukur pengalaman itu dengan tiga angka yang bisa dipertanggungjawabkan. Artikel ini menjelaskan ketiganya dalam bahasa bisnis, menunjukkan cara mengukurnya dengan data yang benar, dan menyusun urutan perbaikan yang memberi hasil terbesar lebih dulu.

Tiga metrik, tiga pertanyaan pengunjung

Cara termudah memahami ketiga metrik ini adalah menerjemahkannya menjadi pertanyaan yang dirasakan pengunjung.

LCP — "kapan saya bisa mulai membaca?"

Largest Contentful Paint mengukur berapa lama sampai elemen terbesar di layar tampil: biasanya gambar utama atau judul besar. Selama ini belum terjadi, pengunjung menatap halaman yang belum berarti apa-apa. Target yang dianggap baik adalah di bawah 2,5 detik.

INP — "kenapa tidak ada yang terjadi saat saya menekan?"

Interaction to Next Paint mengukur jeda antara pengunjung berinteraksi — menekan tombol, membuka menu, mengetik — dan halaman menunjukkan respons. Ini metrik yang paling mudah dirasakan dan paling merusak kepercayaan ketika buruk. Target baik: di bawah 200 milidetik.

CLS — "kenapa tombolnya pindah?"

Cumulative Layout Shift mengukur seberapa banyak isi halaman bergeser sendiri saat dimuat. Pergeseran menyebabkan salah tekan, dan salah tekan menyebabkan orang pergi. Target baik: di bawah 0,1.

Data lapangan versus data laboratorium

Perbedaan ini menentukan apakah pengukuran Anda berguna atau menyesatkan. Data laboratorium berasal dari uji tunggal di lingkungan terkendali. Ia berguna untuk membandingkan sebelum dan sesudah perbaikan, karena kondisinya konsisten.

Data lapangan berasal dari pengunjung sungguhan dengan perangkat dan jaringan mereka sendiri. Inilah yang dipakai mesin pencari untuk menilai, dan inilah yang mencerminkan pengalaman nyata. Angka lapangan hampir selalu lebih buruk daripada angka laboratorium, terutama di Indonesia, di mana sebagian besar kunjungan datang dari ponsel dengan jaringan seluler.

Aturan praktisnya: pakai data laboratorium untuk mendiagnosis dan membuktikan perbaikan, pakai data lapangan untuk menilai apakah situs Anda benar-benar sehat. Jangan merayakan skor laboratorium yang tinggi kalau data lapangan masih merah.

Penyebab LCP lambat, diurutkan dari yang paling sering

1. Gambar utama terlalu besar. Foto beberapa megabita yang dikecilkan lewat CSS tetap harus diunduh utuh. Ini penyebab nomor satu di hampir semua situs bisnis.
2. Gambar utama dimuat terlambat. Menandai gambar utama sebagai "muat belakangan" justru menghukum LCP; penandaan itu hanya untuk gambar di bawah layar.
3. Font yang memblokir tampilan. Teks tidak muncul sampai fontnya selesai diunduh. Menyiapkan cadangan tampilan segera menyelesaikan sebagian besar kasus.
4. Skrip pihak ketiga di kepala halaman. Setiap skrip yang harus diunduh sebelum halaman dirender menunda semuanya.
5. Waktu tanggap server yang lambat. Kalau server butuh satu detik hanya untuk mulai menjawab, satu detik itu tidak bisa ditebus di sisi peramban.

Perbaikan gambar yang hampir selalu berhasil

Empat langkah ini biasanya memangkas ukuran gambar delapan puluh persen atau lebih tanpa perbedaan yang terlihat: ubah ke format modern, sediakan beberapa ukuran untuk lebar layar berbeda, tetapkan dimensi eksplisit pada markup, dan pastikan gambar tidak lebih besar dari ruang tampilnya.

Langkah ketiga sekaligus memperbaiki CLS, karena peramban bisa menyediakan ruang sebelum gambarnya datang.

Penyebab INP buruk

INP hampir selalu soal JavaScript. Ketika utas utama peramban sibuk mengeksekusi kode, ia tidak bisa merespons sentuhan. Penyebab yang paling sering ditemukan:

• Terlalu banyak skrip pihak ketiga. Pelacak, obrolan langsung, peta, widget ulasan — semuanya menumpuk di utas yang sama.
• Kerangka kerja yang merender ulang seluruh halaman untuk perubahan kecil.
• Pekerjaan berat yang dijalankan saat halaman dimuat, padahal bisa ditunda sampai benar-benar dibutuhkan.

Perbaikan paling efektif biasanya bukan mengoptimalkan kode, melainkan mengurangi jumlah kode. Audit skrip pihak ketiga sekali setiap kuartal: hampir selalu ada satu atau dua yang dipasang untuk keperluan yang sudah lama tidak ada.

Skrip pihak ketiga adalah utang yang dibayar oleh setiap pengunjung, setiap kunjungan, selama skrip itu masih terpasang.

Penyebab CLS dan cara menghentikannya

CLS punya daftar penyebab yang pendek dan solusi yang jelas.

Penyebab	Solusi
Gambar tanpa dimensi	Tetapkan lebar dan tinggi, atau rasio aspek
Iklan atau widget yang menyisip	Sediakan ruang tetap sejak awal
Font yang berganti dan mengubah tinggi baris	Samakan metrik font cadangan dengan font utama
Banner atau notifikasi yang muncul di atas	Tempatkan melayang, jangan mendorong isi
Isi yang dimuat setelahnya di tengah halaman	Sediakan kerangka penampung berukuran tetap

Urutan pengerjaan yang memberi hasil tercepat

Kalau Anda hanya punya satu hari, urutan ini biasanya memberi perbaikan paling besar.

1. Kompres dan ubah format seluruh gambar di halaman-halaman paling banyak dikunjungi.
2. Tetapkan dimensi pada semua gambar dan sediakan ruang untuk widget.
3. Pindahkan skrip pihak ketiga agar dimuat setelah halaman siap, dan buang yang tidak dipakai.
4. Perbaiki cara font dimuat supaya teks tampil segera dengan cadangan.
5. Aktifkan penyimpanan sementara di sisi peramban dan jaringan pengiriman konten untuk aset statis.

Lima langkah itu jarang membutuhkan perubahan arsitektur, dan pada sebagian besar situs sudah cukup untuk memindahkan skor dari merah ke kuning atau hijau.

Kapan masalahnya arsitektur, bukan optimasi

Ada titik ketika mengoptimalkan tidak lagi cukup. Tandanya: setelah semua gambar dikompres dan skrip dirapikan, LCP tetap di atas empat detik, atau INP tetap buruk di ponsel kelas menengah.

Biasanya penyebabnya satu — halaman dirender sepenuhnya di peramban. Ketika isi halaman baru terbentuk setelah JavaScript diunduh, diurai, dan dijalankan, semua metrik menanggung penalti yang sama. Perbaikannya adalah memindahkan pembentukan isi ke sisi server, sehingga peramban menerima HTML yang sudah jadi.

Perubahan ini besar, tetapi manfaatnya berlapis: lebih cepat, lebih tahan jaringan buruk, lebih mudah diakses, dan sekaligus menyelesaikan masalah perayapan yang dibahas di panduan SEO teknis.

Server, hosting, dan waktu tanggap pertama

Semua optimasi di sisi peramban punya batas bawah yang ditentukan satu angka: berapa lama server butuh untuk mulai mengirimkan byte pertama. Kalau angka itu satu setengah detik, maka LCP di bawah dua setengah detik hampir mustahil, seberapa pun rapi gambar dan skrip Anda.

Penyebab waktu tanggap yang lambat biasanya salah satu dari empat hal. Pertama, server berada jauh secara geografis dari pengunjung — situs yang melayani pasar Indonesia tetapi berjalan di pusat data seberang benua menanggung penundaan yang tidak bisa dihilangkan. Kedua, hosting bersama yang kapasitasnya dipakai bergantian dengan puluhan situs lain. Ketiga, halaman yang dibangun ulang dari nol untuk setiap permintaan, lengkap dengan puluhan kueri basis data. Keempat, kueri yang tidak efisien — biasanya satu kueri di dalam perulangan yang berjalan ratusan kali.

Tiga dari empat penyebab itu diselesaikan dengan penyimpanan sementara, bukan dengan menaikkan spesifikasi server. Halaman yang isinya sama untuk semua pengunjung tidak perlu dibangun ulang setiap kali; cukup dibangun sekali, disimpan, lalu disajikan dari simpanan sampai isinya benar-benar berubah.

Lapisan penyimpanan sementara yang perlu dipahami

• Peramban — aset statis seperti gambar, font, dan skrip disimpan di perangkat pengunjung. Kunjungan kedua jadi jauh lebih cepat.
• Jaringan pengiriman konten — salinan aset disebar ke lokasi yang lebih dekat dengan pengunjung, memangkas jarak tempuh.
• Halaman penuh — HTML jadi disimpan dan disajikan tanpa memanggil basis data sama sekali.
• Basis data dan objek — hasil kueri yang mahal disimpan sementara supaya tidak dihitung ulang.

Jebakan yang paling sering muncul justru bukan pada pemasangannya, melainkan pada pembatalannya. Situs yang menyimpan halaman terlalu lama akan menyajikan harga lama, artikel lama, atau formulir dengan token yang sudah kedaluwarsa. Tentukan sejak awal peristiwa apa yang membersihkan simpanan — artikel diterbitkan, produk diubah, pengaturan disimpan — dan uji bahwa pembersihan itu benar-benar terjadi.

Kenyataan jaringan di Indonesia

Sebagian besar kunjungan ke situs bisnis di Indonesia datang dari ponsel, dan sebagian besar di antaranya lewat jaringan seluler yang kualitasnya sangat bervariasi antar-lokasi dan antar-jam. Menguji situs dari komputer kantor dengan sambungan tetap memberi gambaran yang jauh lebih optimistis daripada kenyataan.

Karena itu, dua kebiasaan pengujian layak dijadikan standar. Pertama, selalu uji dengan simulasi ponsel kelas menengah, bukan perangkat kelas atas. Kedua, uji juga dengan simulasi jaringan lambat — bukan untuk mengejar skor, melainkan untuk melihat apa yang dilihat pengunjung ketika sinyalnya sedang tidak bagus. Sering kali di situ terlihat masalah yang tidak muncul sama sekali di jaringan cepat: teks yang kosong berdetik-detik, tombol yang tidak bisa ditekan, atau gambar yang menggeser isi setelah muncul.

Konsekuensi praktisnya: total ukuran halaman jauh lebih penting daripada yang biasa dianggap. Halaman berukuran tiga megabita mungkin terasa wajar di kantor, tetapi di jaringan seluler yang sibuk ia berarti belasan detik menunggu — dan kuota yang terpakai, yang juga diperhatikan sebagian pengunjung.

Daftar periksa sebelum menyatakan selesai

Perbaikan kecepatan mudah terasa selesai padahal belum. Daftar berikut membantu memastikan hasilnya nyata, bukan hanya terasa.

1. Data lapangan tiga halaman terpenting sudah diukur, bukan hanya beranda.
2. Pengujian dilakukan dengan simulasi ponsel dan jaringan seluler, bukan desktop berjaringan cepat.
3. Total ukuran halaman utama tercatat, dan tercatat pula berapa persen berasal dari gambar dan berapa dari skrip.
4. Semua gambar punya dimensi eksplisit, dan tidak ada gambar di atas layar yang ditandai muat-belakangan.
5. Daftar skrip pihak ketiga ditinjau, dan setiap skrip punya alasan yang masih berlaku.
6. Pembersihan simpanan diuji: ubah satu isi, pastikan perubahannya benar-benar tampil.
7. Angka sebelum dan sesudah dicatat di satu tempat, supaya perbaikan berikutnya punya pembanding.

Menghubungkan kecepatan dengan angka bisnis

Agar perbaikan kecepatan mendapat prioritas, ia perlu diterjemahkan ke bahasa yang sama dengan keputusan lain. Caranya: bandingkan rasio konversi pengunjung yang mengalami halaman cepat dan yang mengalami halaman lambat.

Sebagian besar perangkat analytics bisa memisahkan itu. Kalau tidak, pendekatan yang lebih kasar tetap berguna: bandingkan rasio konversi sebelum dan sesudah perbaikan, dalam rentang waktu yang setara, dengan sumber trafik yang sama.

Contoh perhitungan — angka ini ilustrasi, bukan hasil klien tertentu. Kalau halaman menerima empat ribu kunjungan sebulan dengan konversi tiga persen, dan perbaikan kecepatan menaikkannya menjadi tiga setengah persen, tambahannya dua puluh lead per bulan. Dengan nilai lead Rp1 juta, itu Rp20 juta per bulan dari pekerjaan yang biasanya selesai dalam beberapa hari. Kerangka menghitungnya ada di artikel dampak bisnis proyek digital.

Kesalahan umum saat mengejar skor

• Mengoptimalkan beranda saja. Halaman tujuan iklan dan artikel biasanya menerima lebih banyak pengunjung baru.
• Mengejar angka seratus. Selisih antara delapan puluh lima dan seratus jarang terasa oleh pengunjung; selisih antara empat puluh dan delapan puluh sangat terasa.
• Menguji hanya di desktop dengan jaringan cepat. Uji dengan simulasi ponsel kelas menengah dan jaringan seluler.
• Memasang perkakas pemantau yang berat untuk memantau kecepatan — perkakasnya sendiri memperlambat halaman.
• Membandingkan skor lintas alat yang memakai metodologi berbeda; bandingkan alat yang sama dari waktu ke waktu.

Menjaga kecepatan setelah diperbaiki

Kecepatan cenderung memburuk perlahan. Setiap plugin baru, setiap gambar yang diunggah tanpa dikompres, setiap skrip pemasaran yang ditambahkan menyumbang sedikit. Tanpa pemeriksaan berkala, situs yang tadinya hijau bisa kembali merah dalam enam bulan tanpa ada satu perubahan besar pun.

Dua pagar yang murah dan efektif: kompresi gambar otomatis pada jalur unggah, sehingga tidak ada gambar mentah yang bisa masuk; dan pemeriksaan bulanan terhadap tiga halaman paling banyak dikunjungi, dicatat di satu tempat agar trennya terlihat.

Prioritas halaman: mana yang dikerjakan lebih dulu

Tidak semua halaman layak mendapat perhatian yang sama. Urutkan dengan mengalikan dua angka: berapa banyak pengunjung baru yang masuk lewat halaman itu, dan seberapa dekat halaman itu dengan keputusan membeli. Halaman tujuan iklan biasanya menang telak di kedua sumbu, disusul artikel yang mendatangkan trafik pencarian, baru kemudian beranda.

Beranda sering diperbaiki lebih dulu semata karena ia yang paling sering dilihat pemilik situs — bukan karena ia yang paling sering dilihat calon pelanggan. Periksa datanya sebelum memutuskan: pada banyak situs bisnis, lebih dari separuh pengunjung baru mendarat di halaman selain beranda dan tidak pernah membukanya sama sekali.

Menyampaikan hasilnya ke pihak lain

Pekerjaan kecepatan sering sulit mendapat persetujuan karena hasilnya tidak terlihat seperti fitur baru. Cara paling efektif menjelaskannya bukan dengan menunjukkan skor, melainkan dengan menunjukkan rekaman: buka halaman lama dan halaman baru berdampingan pada simulasi jaringan seluler, lalu biarkan orang melihat sendiri selisihnya.

Setelah itu barulah angka disampaikan, dan cukup tiga: waktu sampai halaman terbaca, total ukuran halaman, dan rasio konversi sebelum-sesudah. Tiga angka itu bisa dipahami tanpa latar belakang teknis, dan ketiganya bisa diperiksa ulang oleh siapa pun.

Ringkasan

Pahami ketiga metrik sebagai tiga pertanyaan pengunjung. Ukur dengan data lapangan, bukan hanya laboratorium. Kerjakan gambar dulu, lalu skrip pihak ketiga, lalu font. Naikkan ke perubahan arsitektur hanya kalau optimasi sudah mentok. Dan terjemahkan hasilnya ke angka bisnis, supaya pekerjaan ini mendapat prioritas yang pantas.

Ingin situs Anda diukur dan diperbaiki? Hubungi tim kami untuk pemeriksaan kecepatan.