Website Lemot: Cara Tahu Berapa Pelanggan yang Hilang dan Apa yang Perlu Dibetulkan

Website lemot jarang kehilangan pelanggan karena orang sabar menunggu lalu kecewa — yang terjadi, mereka menutup tab sebelum sempat melihat harga atau tombol WhatsApp. Patokan yang dipakai Google: sebuah halaman dianggap baik kalau LCP di bawah 2,5 detik, INP di bawah 200 milidetik, dan CLS di bawah 0,1, diukur dari pengalaman 75% pengunjung asli — bukan dari satu kali tes di laptop kantormu. Angka itu penting karena menentukan dua hal sekaligus: berapa banyak orang yang bertahan cukup lama untuk menghubungimu, dan seberapa mudah Google menampilkan halamanmu saat isinya seimbang dengan pesaing.

Yang sering terjadi di lapangan: pemilik bisnis membuka situsnya sendiri, merasa "biasa saja", lalu menyimpulkan tidak ada masalah. Padahal situs itu sudah tersimpan di cache browsernya, dibuka lewat WiFi kantor, di layar besar. Pelangganmu membukanya pertama kali, lewat jaringan seluler, sambil jalan. Dua pengalaman itu bisa berbeda tiga sampai lima kali lipat.

Apa arti "lemot" kalau diterjemahkan ke angka?

Google memakai tiga ukuran yang disebut Core Web Vitals. Ketiganya mengukur hal berbeda, dan situsmu bisa lulus di satu ukuran tapi gagal total di yang lain. Batas berikut adalah angka resmi yang dipublikasikan Google di dokumentasi Web Vitals.

Ukuran	Yang sebenarnya diukur	Batas "baik"	Mulai dianggap "buruk"
LCP	Berapa lama sampai isi utama halaman terlihat — biasanya gambar besar atau judul di layar pertama	2,5 detik atau kurang	Lebih dari 4 detik
INP	Berapa lama halaman merespons setelah pengunjung menekan sesuatu — tombol, menu, form	200 milidetik atau kurang	Lebih dari 500 milidetik
CLS	Seberapa sering isi halaman meloncat sendiri saat sedang dibaca	0,1 atau kurang	Lebih dari 0,25

Dua catatan yang sering ketinggalan. Pertama, ketiganya dinilai pada persentil ke-75 — artinya bukan rata-rata, tapi pengalaman pengunjung yang agak apes. Kalau tiga dari empat pengunjungmu mendapat pengalaman baik, kamu lulus. Kedua, INP menggantikan ukuran lama bernama FID sejak Maret 2024. Kalau kamu membaca panduan yang masih menyebut FID, panduan itu sudah ketinggalan dan kemungkinan besar sisanya juga.

Ukuran ketiga, CLS, adalah yang paling sering diabaikan padahal paling menyebalkan buat pengunjung. Ini yang terjadi saat kamu hendak menekan tombol "Chat WhatsApp", lalu sebuah banner muncul di atasnya dan jarimu malah mendarat di iklan. Angka loading bisa saja bagus, tapi orang tetap pergi.

Kenapa hasil tesmu bagus tapi pelanggan tetap mengeluh?

Ini sumber kebingungan nomor satu. Alat seperti PageSpeed Insights menampilkan dua jenis data sekaligus, dan keduanya sering tidak sepakat. Google sendiri menjelaskan kenapa data lab dan data lapangan bisa berbeda jauh.

Data lab adalah simulasi: satu perangkat, satu kondisi jaringan yang ditetapkan, dijalankan saat itu juga. Berguna untuk mencari penyebab, karena hasilnya bisa diulang. Data lapangan diambil dari pengunjung Chrome sungguhan selama 28 hari terakhir. Ini yang mendekati kenyataan bisnismu, dan ini juga yang muncul di laporan Core Web Vitals di Search Console.

Konsekuensinya penting untuk ekspektasi: kalau kamu memperbaiki situs hari ini, laporan lapangan tidak langsung ikut membaik. Angkanya bergerak pelan karena masih mencampur 28 hari data lama. Banyak orang panik di hari ketiga, mengubah-ubah lagi, lalu tidak pernah tahu perbaikan mana yang sebenarnya bekerja. Tunggu penuh empat minggu sebelum menilai.

Satu hal lagi: kalau situsmu masih sepi pengunjung, data lapangan bisa saja kosong sama sekali. Itu bukan tanda situsmu buruk — cuma belum cukup data. Pakai data lab dulu, dan pastikan situsnya memang sudah bisa ditemukan orang; cara mengeceknya ada di kenapa website tidak muncul di Google.

Lambatnya datang dari mana, dan siapa yang harus membetulkan?

Ini bagian yang jarang ada di panduan umum. Kebanyakan artikel memberi daftar sepuluh tips tanpa memberitahu mana yang bisa kamu kerjakan sendiri sore ini, dan mana yang harus dipegang orang teknis. Tabel di bawah memisahkannya.

Gejala yang kamu lihat	Penyebab paling sering	Siapa yang bisa membetulkan	Berat kerjanya
Layar putih lama sebelum apa pun muncul	Server hosting lambat merespons, atau paket hosting berbagi terlalu penuh	Penyedia hosting atau orang teknismu	Sedang — sering selesai dengan pindah paket
Teks muncul duluan, gambar besar menyusul lama	Foto diunggah langsung dari kamera atau HP tanpa dikecilkan	Kamu sendiri	Ringan — beberapa jam sekali kerja
Halaman terlihat penuh tapi tombol belum bisa ditekan	Terlalu banyak skrip: plugin chat, pelacak iklan, animasi, font eksternal	Orang teknis, dengan keputusan dari kamu soal mana yang dibuang	Sedang
Isi halaman meloncat saat sedang dibaca	Gambar atau iklan tanpa ukuran tetap, banner yang muncul belakangan	Orang teknis	Ringan sampai sedang
Cepat di laptop, berat di HP	Gambar versi desktop dipaksakan ke layar kecil, menu berbasis skrip berat	Orang teknis	Sedang
Dulu cepat, sekarang makin lambat tiap bulan	Plugin menumpuk, database menggemuk, tema tidak pernah diperbarui	Perawatan rutin	Berulang — bukan sekali kerja

Baris terakhir yang paling sering jadi jebakan. Situs yang dibangun rapi pun akan melambat kalau tidak dirawat, dan biaya membiarkannya biasanya lebih besar daripada biaya merawatnya — pos-posnya kami rinci di biaya maintenance website per tahun.

Urutan perbaikan yang benar-benar menggerakkan angka

Kerjakan berurutan. Melompat ke nomor lima sebelum nomor satu beres cuma membuatmu tidak tahu mana yang berhasil.

1. Tes halaman yang benar. Bukan beranda saja. Tes halaman yang paling banyak menerima pengunjung dan halaman layanan yang paling menghasilkan. Buka PageSpeed Insights, masukkan URL-nya, dan baca bagian mobile lebih dulu.
2. Catat angka awalnya. Tulis LCP, INP, dan CLS hari ini di catatan. Tanpa titik awal, kamu tidak bisa membuktikan apa pun empat minggu lagi.
3. Kecilkan gambar. Ini hampir selalu perbaikan terbesar dengan usaha paling kecil. Foto langsung dari HP sering 4–6 MB; untuk web, di bawah 300 KB biasanya sudah lebih dari cukup.
4. Buang yang tidak dipakai. Buka daftar plugin dan skrip pihak ketiga. Widget chat yang tidak pernah dibalas, pelacak iklan dari kampanye yang sudah berhenti, font dekoratif yang cuma dipakai di satu judul — semuanya tetap ikut dimuat.
5. Beri ukuran tetap pada gambar dan area iklan supaya isi halaman tidak meloncat. Ini yang memperbaiki CLS.
6. Cek waktu respons servernya. Kalau setelah semua di atas layar masih putih beberapa detik di awal, masalahnya di hosting, bukan di halamanmu.
7. Buka laporan Core Web Vitals di Search Console untuk melihat berapa banyak halaman yang bermasalah, bukan cuma satu yang kamu tes. Panduan membacanya ada di bantuan resmi Search Console.
8. Diamkan empat minggu, lalu ukur ulang. Bandingkan dengan catatan di langkah dua.

Untuk situs bisnis lokal berukuran wajar — lima sampai sepuluh halaman, beberapa galeri foto — langkah tiga dan empat saja sering sudah memindahkan LCP dari kategori buruk ke kategori baik. Kecepatan juga bagian tetap dari pekerjaan teknis bulanan di paket SEO kami, karena angka ini cenderung merosot lagi kalau tidak dijaga.

Seberapa cepat yang sebenarnya kamu butuhkan?

Tidak semua situs perlu mengejar skor sempurna. Patokan yang lebih berguna: lebih cepat dari pesaing yang muncul di atasmu untuk pencarian yang sama. Ambil tiga situs pesaing di Kota Yogyakarta atau Sleman yang muncul saat kamu mengetik layananmu, masukkan ke alat yang sama, dan bandingkan angka mobile-nya. Kalau mereka semua di angka empat detik dan kamu di dua detik, kecepatan bukan lagi masalahmu — dan tenaga berikutnya lebih baik dipakai untuk hal lain.

Perlu jujur soal satu hal: memperbaiki kecepatan jarang membuat peringkatmu melompat sendirian. Google memperhitungkan pengalaman halaman, tapi relevansi dan kelengkapan isi tetap yang menentukan lebih dulu. Halaman cepat yang isinya tipis tetap kalah dari halaman lambat yang benar-benar menjawab pertanyaan orang. Yang berubah adalah situasi seri — saat isimu setara dengan pesaing, halaman yang lebih enak dipakai punya peluang lebih baik. Ritme perubahannya juga bukan harian; gambaran waktunya ada di berapa lama SEO baru kelihatan hasilnya.

Kapan mengejar kecepatan bukan prioritasmu

Ada tiga situasi di mana kami menyarankan menunda pekerjaan ini.

Pengunjungmu memang sedikit. Kalau situsmu dibuka lima puluh orang sebulan, memangkas satu detik menyelamatkan angka yang terlalu kecil untuk terasa. Yang lebih mendesak adalah membuat situsmu ditemukan sama sekali.

Chat sudah masuk tapi banyak yang menguap. Kalau bocornya ada di tindak lanjut, situs yang lebih cepat cuma menambah chat yang tetap tidak dibalas. Bereskan dulu bagian itu — kami bahas di chat masuk banyak tapi tidak jadi beli.

Situsnya memang sudah tidak layak diperbaiki. Ada titik di mana menambal tema lama yang penuh plugin usang lebih mahal daripada membangun ulang dari fondasi yang benar. Tandanya: sudah dua kali diperbaiki dan kembali melambat dalam hitungan bulan, atau tidak ada yang berani menyentuh temanya karena takut rusak. Kalau kamu di titik itu, pertimbangan dan biayanya kami buka di halaman pembuatan website di Jogja.

Pertanyaan yang sering muncul

Skor PageSpeed saya 60, apakah itu buruk?

Skor gabungan itu berasal dari data lab dan bukan yang dipakai Google untuk menilai pengalaman halaman. Yang perlu kamu lihat adalah tiga ukuran lapangan — LCP, INP, CLS — dan apakah masing-masing masuk kategori baik. Situs dengan skor 60 tapi ketiga ukuran lapangannya hijau berada di posisi lebih baik daripada situs berskor 90 yang data lapangannya merah.

Apakah pindah hosting otomatis membuat website cepat?

Hanya kalau penyebabnya memang server. Pindah hosting memperbaiki waktu respons awal — layar putih di detik pertama. Kalau lambatnya karena gambar 5 MB dan dua belas plugin, gambar itu tetap 5 MB di hosting baru. Tes dulu, baru putuskan.

Sudah pakai plugin cache, kenapa masih lambat?

Cache mempercepat pengiriman halaman yang sudah jadi, tapi tidak mengurangi apa yang ada di dalam halaman itu. Gambar besar tetap besar, skrip pihak ketiga tetap diunduh dari server orang lain. Cache membantu, tapi bukan pengganti membereskan isinya.

Berapa lama sampai perbaikan kecepatan terlihat di Google?

Data lapangan bergerak dalam jendela 28 hari, jadi angka penuhnya baru terbaca sekitar empat minggu setelah perbaikan selesai. Efeknya ke peringkat, kalau ada, menyusul setelah itu dan bergantung pada seberapa ketat persaingan di kata kunci yang kamu incar.

Apakah menghapus semua gambar akan membuat situs jauh lebih cepat?

Cepat, ya. Tapi untuk bisnis lokal — kuliner, klinik, properti, travel — foto sering justru yang membuat orang percaya dan menghubungi. Targetnya bukan menghapus, tapi mengecilkan ukuran filenya dan memastikan gambar yang berada jauh di bawah baru dimuat ketika pengunjung menggulir ke sana.

Langkah berikutnya

Kalau kamu sudah mengecek angkanya dan tidak yakin bagian mana yang layak dikerjakan lebih dulu — atau hasil tesnya saling bertentangan antara laptop dan HP — kirim alamat situsmu lewat audit gratis. Kami cek ketiga ukurannya, bandingkan dengan dua pesaing terdekatmu, lalu balas dengan daftar pendek berisi apa yang perlu dibetulkan, oleh siapa, dan mana yang sebetulnya bisa dibiarkan dulu.