Website lambat membuat calon klien kembali ke hasil pencarian sebelum sempat melihat layanan dan tombol kontakmu. Bagi Google, kecepatan ikut dinilai meski bukan penentu utama, dan perbaikannya belum tentu berarti pindah ke hosting yang lebih mahal.
Cek dulu pengalaman pengunjung nyata dan tiga ukuran kecepatan dari Google, lalu perbaiki penyebab yang paling berdampak. Setelah itu, baru putuskan perlu upgrade hosting atau tidak, dan bagi tugas dengan developer agar website tetap cepat.
Jawaban singkatnya:
- Cek pengalaman pengunjung nyata di HP, bukan hanya skor 0–100.
- Perbaiki foto utama dan skrip tambahan lebih dulu. Keduanya paling sering menjadi penyebab di website bisnis jasa.
- Upgrade hosting hanya bila respons server lambat di banyak halaman.
Kecepatan dan Peringkat Google: Berpengaruh, tetapi Bukan Penentu
Google memakai kecepatan sebagai salah satu sinyal peringkat, tetapi pengaruhnya terbatas. Dalam pengumuman Google tahun 2018, sinyal kecepatan di pencarian HP disebut hanya berdampak pada halaman yang paling lambat dan sebagian kecil kueri.
Kini pengalaman halaman diukur lewat Core Web Vitals, yaitu tiga ukuran yang dipakai sistem peringkat Google.
Meski begitu, dokumentasi pengalaman halaman Google menegaskan tidak ada satu sinyal yang menentukan peringkat sendirian. Hasil yang baik juga tidak menjamin posisi teratas.
Google tetap mengutamakan konten yang paling relevan, sehingga halaman lambat yang sangat relevan masih berpeluang berperingkat tinggi. Kecepatan baru menjadi pembeda saat beberapa halaman sama-sama relevan.
Karena itu, website yang cepat tetap sulit mendatangkan klien bila isinya belum menjawab kebutuhan mereka.
Cara Mengecek Kecepatan Website: Data Pengunjung Nyata Dulu, Skor Belakangan
Untuk tahu pengalaman calon klien, lihat data pengunjung nyata dari alat gratis Google, bukan hanya skor 0–100. Skor itu hasil satu kali simulasi, jadi wajar bila berubah walau tidak ada yang diubah.
Menurut Google, perubahannya dipengaruhi kondisi jaringan, perangkat, beban server penguji, dan lokasi pusat data penguji. Uji dua sampai tiga kali, lalu lihat kisarannya.
Sebagai contoh hipotetis yang dipakai sepanjang artikel, bayangkan day spa di Jimbaran dengan enam terapis. Tamunya warga lokal dan wisatawan yang menginap di sekitar Jimbaran, dan banyak yang membuka website lewat Wi-Fi hotel atau data seluler.
Websitenya dibuat freelancer dua tahun lalu dengan WordPress dan page builder, berisi sekitar 15 halaman dan 35 plugin.
Beberapa tamu mengeluh halaman paket layanan lama terbuka, dan freelancer menyarankan pindah ke hosting yang lebih mahal. Sebelum membayar lebih, pemiliknya mengecek datanya dulu.
Pilih Halaman yang Paling Sering Dibuka
Setiap halaman punya hasil pengukuran sendiri. Mulailah dari beranda dan dua sampai tiga halaman yang paling sering dibuka calon klien, seperti halaman layanan, paket, atau kontak.
Buka tab Seluler lebih dulu. Banyak calon klien bisnis jasa membuka website lewat HP setelah menemukan bisnismu di Google atau Google Maps, sering dengan koneksi yang tidak stabil.
PageSpeed Insights: Bagian Atas dan Bagian Bawah
Laporan PageSpeed Insights punya dua bagian dengan fungsi berbeda.
Bagian atas berisi data pengunjung nyata dari Chrome User Experience Report, yang merekam kunjungan pengguna Chrome selama 28 hari terakhir. Status lulus atau gagal Core Web Vitals di bagian ini menggambarkan pengalaman pengguna yang sebenarnya.
Bagian bawah berisi skor 0–100 dari simulasi Lighthouse, alat uji milik Google, dengan kondisi HP kelas menengah di jaringan seluler. Fungsinya membantu menemukan penyebab masalah, bukan menentukan lulus atau gagalnya Core Web Vitals.
Website bisnis kecil sering belum punya cukup data untuk satu halaman. Dalam kondisi itu, PageSpeed Insights memakai data seluruh situs. Bila data seluruh situs pun belum ada, laporan hanya menampilkan hasil simulasi.
Menurut dokumentasi resmi PageSpeed Insights, halaman juga harus publik dan bisa diindeks agar masuk ke data pengunjung nyata.
Keterangan “data tidak tersedia” masih wajar, tetapi jangan lalu berpatokan pada skor 0–100. Cocokkan waktu munculnya konten utama dan pergeseran tata letak di hasil simulasi dengan batas baik Core Web Vitals.
Simulasi tidak mengukur respons halaman saat diketuk, jadi ukuran itu baru bisa dinilai setelah data pengunjung nyata tersedia.
Pada contoh spa, beranda belum punya data pengunjung nyata sendiri. Data seluruh situs berstatus gagal karena waktu hingga konten utama muncul (LCP) sekitar 5 detik, dan skor simulasinya hanya 29.
Laporan Core Web Vitals di Search Console
Search Console juga punya laporan Core Web Vitals yang memakai data pengunjung nyata. Di Search Console berbahasa Indonesia, laporan ini bernama Data Web Inti.
Laporan ini mengelompokkan halaman yang mirip, memisahkan hasil HP dan komputer, dan memberi status berdasarkan ukuran terburuk di tiap kelompok.
Dari sini kamu bisa tahu apakah masalah hanya ada di satu halaman atau meluas. Contohnya, beberapa halaman paket bisa bermasalah serupa karena memakai template yang sama.
Laporan ini baru bisa dibuka setelah website terhubung ke Google Search Console. Tanpa akses sendiri, kamu hanya bisa mengandalkan tangkapan layar atau laporan dari vendor yang menangani website.
Cek dari HP Sendiri
Buka juga website dari HP sendiri dengan mode samaran dan data seluler, bukan Wi-Fi kantor. Perhatikan berapa lama foto utama dan tombol kontak baru muncul.
Jadikan hasilnya pelengkap, bukan patokan utama. HP pemilik biasanya sudah menyimpan halaman di cache, memakai Wi-Fi cepat, dan sering berkelas atas, sehingga website terasa lebih cepat daripada yang tertulis di laporan.
Sebaliknya, bila website hanya lambat di satu HP atau jaringan tertentu, masalahnya mungkin ada di perangkat atau koneksi itu.
Untuk diagnosis yang lebih rinci, developer bisa memakai Lighthouse di Chrome atau WebPageTest. Bagi sebagian besar website bisnis, PageSpeed Insights dan Search Console sudah cukup sebagai langkah awal.
Core Web Vitals: Tiga Ukuran dan Batas Baik Menurut Google
Core Web Vitals adalah tiga ukuran pengalaman pengguna: kecepatan menampilkan konten utama, respons halaman saat diketuk, dan kestabilan tata letak.
Menurut penjelasan ambang Core Web Vitals di web.dev, batas berikut berlaku untuk HP maupun komputer.
- LCP (Largest Contentful Paint): waktu hingga konten utama di layar pertama muncul, biasanya foto besar atau judul. Baik: maksimal 2,5 detik. Buruk: lebih dari 4 detik. Contoh penyebab: foto slider besar yang langsung diunggah dari kamera.
- INP (Interaction to Next Paint): waktu halaman merespons interaksi, misalnya saat membuka menu atau menekan tombol booking. Baik: maksimal 200 milidetik. Buruk: lebih dari 500 milidetik. Contoh penyebab: widget chat dan feed media sosial yang disematkan.
- CLS (Cumulative Layout Shift): seberapa banyak tata letak bergeser selama halaman dimuat, misalnya tombol berpindah karena banner muncul. Baik: maksimal 0,1. Buruk: lebih dari 0,25. Contoh penyebab: banner promosi dan gambar tanpa dimensi tetap.
Nilai di antara batas baik dan buruk masuk kategori perlu ditingkatkan. Google menilai ketiganya pada persentil ke-75. Artinya, halaman dinilai baik bila setidaknya 75% kunjungan memenuhi batas baik.
Sejak 12 Maret 2024, INP menggantikan FID (First Input Delay), ukuran lama untuk respons pertama halaman. Panduan yang masih memakai FID sudah tidak sesuai dengan standar saat ini.
Lolos Tiga Batas Baik di HP Sudah Cukup
Setelah ketiga ukuran memenuhi batas baik di HP, alihkan fokus ke hal yang lebih berdampak pada bisnis: kejelasan informasi layanan, kualitas konten, dan kemudahan menemukan tombol kontak.
Dalam dokumentasi pengalaman halaman yang sama, Google menyebut bahwa mengejar skor sempurna hanya demi SEO mungkin bukan langkah yang tepat.
Pada contoh spa, LCP masuk kategori buruk, sedangkan INP dan CLS perlu ditingkatkan. Targetnya adalah memenuhi ketiga batas baik di HP.
LCP Paling Sering Gagal
Bila bingung mulai dari mana, periksa LCP dulu. Menurut catatan rilis Chrome UX Report, data September 2026 mencatat 68,3% dari sekitar 18,4 juta website di dunia punya LCP yang baik.
Angka itu lebih rendah daripada CLS (81,7%) dan INP (85,4%). Datanya global, bukan khusus Indonesia, tetapi menunjukkan bahwa LCP paling sering bermasalah.
Penyebab Website Lambat yang Paling Sering Ditemui di Bisnis Jasa
Di website bisnis jasa, penyebab paling sering adalah foto berukuran besar dan skrip tambahan, bukan hosting. Urutan perbaikannya mengikuti ukuran yang gagal.
Bila LCP yang gagal, mulai dari foto utama, kurangi skrip tambahan, lalu rapikan cache dan plugin. Server baru perlu dicurigai bila semua halaman lambat sejak respons pertama.
Contoh di bagian ini memakai WordPress. Bila websitemu dibuat dengan platform lain, langkah untuk foto dan skrip tetap berlaku. Pengaturan cache, plugin, dan server bergantung pada fitur yang disediakan platformmu.
1. Foto dan Video di Layar Pertama (Memengaruhi LCP)
Foto slider atau banner yang langsung diunggah dari kamera bisa berukuran beberapa MB. Video latar yang diputar otomatis di layar pertama juga menambah beban. Di bagian diagnosis PageSpeed Insights, petunjuknya biasanya berupa “Pengiriman gambar” dan “Penemuan permintaan LCP”.
Foto utama juga bisa terlambat muncul karena tema atau slider memakai lazy load, yaitu fitur yang menunda pemuatan gambar.
Menurut panduan Google untuk mengoptimalkan LCP, penundaan ini menambah waktu tunggu. Karena itu, jangan pasang lazy load pada foto utama di layar pertama. Pakai fitur ini hanya untuk gambar di bagian bawah halaman.
Sebelum mengunggah, perkecil foto sampai kira-kira selebar tampilannya di layar, karena ukuran asli kamera jauh melebihi yang dibutuhkan. Lalu kompres dengan alat kompres gambar atau plugin kompresi, dan pakai format modern seperti WebP bila website mendukungnya.
Satu foto utama yang ringan biasanya lebih efektif daripada slider berisi lima foto.
Contoh website spa, slider beranda berisi lima foto interior berukuran asli dari kamera. Slider itu diganti satu foto ruang perawatan yang sudah diperkecil dan dikompres.
Masalah serupa juga bisa ditemukan di website kontraktor yang menampilkan puluhan foto proyek sebelum dan sesudah dalam ukuran asli.
2. Skrip Tambahan dari Pihak Ketiga (Memengaruhi INP dan CLS)
Skrip adalah kode yang dijalankan browser untuk menambah fungsi di halaman. Sebagian skrip berasal dari layanan pihak ketiga, yaitu penyedia di luar pengelola website. Contoh yang sering ditemukan di website bisnis:
- Widget chat dan tombol WhatsApp melayang dari plugin.
- Feed Instagram, peta Google, dan video YouTube yang disematkan.
- Widget booking dari penyedia lain.
- Kode pelacak iklan untuk mengukur aktivitas pengunjung.
Setiap skrip menambah pekerjaan browser. Bila jumlahnya terlalu banyak, halaman lambat merespons saat diketuk, atau bergeser saat widget muncul setelah konten utama.
Petunjuknya di PageSpeed Insights biasanya berupa “Pihak ketiga” dan “Permintaan yang memblokir render”.
Pertahankan hanya fitur yang benar-benar dibutuhkan:
- Hapus widget dan kode yang sudah tidak dipakai.
- Pasang widget hanya di halaman yang membutuhkannya, misalnya peta di halaman kontak.
- Ganti feed Instagram dengan beberapa foto biasa dan satu tautan ke akun Instagram bisnis.
- Pakai gambar pratinjau untuk peta dan video, agar kontennya baru dimuat saat diklik.
- Pakai tautan WhatsApp biasa tanpa plugin tambahan.
Untuk CLS, beri dimensi tetap pada gambar dan sediakan ruang tetap untuk banner promosi. Dengan begitu, tombol tidak bergeser saat halaman selesai dimuat.
Contoh website spa, beranda memuat berbagai jenis skrip itu sekaligus. Feed Instagram dihapus dari beranda, dan widget booking hanya dipasang di halaman paket. Beranda jadi lebih ringan tanpa menghilangkan jalur pemesanan.
3. Tema, Page Builder, Plugin, dan Cache (Memengaruhi LCP dan INP)
Tema dengan banyak fitur, page builder, dan plugin yang menumpuk membuat website memuat fitur yang sebenarnya tidak dipakai. Tanpa cache halaman, server juga harus menyusun halaman dari awal untuk setiap pengunjung.
Petunjuknya di PageSpeed Insights biasanya berupa “Permintaan yang memblokir render” dan “Masa aktif cache”.
Aktifkan cache halaman dari satu sumber saja, plugin atau fitur hosting, karena beberapa sistem cache sekaligus bisa saling bentrok. Bersihkan cache setiap kali halaman diubah.
Cache mempercepat respons server, tetapi tidak mengecilkan foto yang berat atau mengurangi skrip pihak ketiga, jadi jarang cukup sendirian.
Selanjutnya, hapus plugin yang tidak dipakai. Setelah membuat backup (salinan cadangan website), perbarui tema, plugin, dan WordPress. Jumlah plugin saja belum membuktikan plugin sebagai penyebab.
Untuk mencari plugin yang memperlambat, nonaktifkan satu per satu di salinan website, lalu uji ulang setiap kali.
Contoh website spa yang memakai sekitar 35 plugin, dan sebagian sudah tidak dipakai, jadi daftarnya layak diperiksa ulang.
Bila halaman masih gagal memenuhi batas Core Web Vitals setelah semua langkah ini, barulah pertimbangkan mengganti tema atau page builder. Langkah ini bisa berarti merombak website.
4. Server dan Hosting (Memengaruhi LCP lewat TTFB)
Paket hosting termurah sering berupa hosting bersama (shared hosting), yaitu satu server yang dipakai banyak website. Lokasi server yang jauh dari pengunjung atau perangkat lunak server yang usang juga bisa memperlambat respons pertama.
Petunjuknya di PageSpeed Insights biasanya berupa “Latensi permintaan dokumen”.
Ukuran yang dipakai di sini adalah TTFB (Time to First Byte), yaitu waktu sampai server mengirim respons pertama ke browser. TTFB bukan bagian dari Core Web Vitals, tetapi tampil sebagai ukuran eksperimental di data pengunjung nyata PageSpeed Insights.
Panduan TTFB di web.dev memakai sekitar 0,8 detik sebagai acuan kasar batas baik.
Bila semua halaman lambat sejak respons pertama, termasuk halaman sederhana dengan sedikit gambar, server perlu dibuktikan sebagai penyebab sebelum kamu membayar lebih.
Lain halnya bila website tiba-tiba melambat tanpa perubahan apa pun dari pengelola. Dalam kondisi itu, periksa kemungkinan peretasan lewat laporan Masalah keamanan di Search Console, lalu hubungi penyedia hosting.
Perlu Upgrade Hosting? Cara Membuktikannya sebelum Membayar Lebih
Upgrade hosting hanya membantu bila server memang penyebabnya. Masalah foto, skrip, tema, dan cache biasanya bisa diperbaiki tanpa pindah hosting, jadi periksa data yang sudah ada sebelum menambah biaya.
Sebagai keterbukaan, Taiciken menyediakan jasa SEO dan pembuatan website, bukan layanan hosting.
Tanda Server Memang Menjadi Penyebab
Server patut dicurigai bila beberapa tanda berikut muncul bersamaan:
- TTFB di atas sekitar 0,8 detik di banyak halaman, termasuk halaman yang hampir hanya berisi teks. Artinya, server lambat mengirim halaman.
- Bagian diagnosis menyebut respons dokumen lambat. Artinya, hambatan terjadi sebelum konten mulai dimuat.
- Dasbor admin website juga lambat. Artinya, beban server tinggi, bukan hanya masalah di tampilan depan.
- Ada email peringatan batas sumber daya dari penyedia hosting. Artinya, kapasitas paket mungkin sudah tidak cukup.
- Muncul error server saat pengunjung ramai. Artinya, server kewalahan.
Dalam kondisi itu, hubungi penyedia hosting untuk mencari penyebabnya. Ingat juga bahwa TTFB mencakup pengalihan, pencarian alamat server, dan proses koneksi, jadi angkanya tidak murni mengukur kerja server.
Contohnya, sebuah kantor akuntan di Cirebon punya website yang hampir seluruhnya berisi teks, tetapi semua halamannya lambat merespons. Pada kasus seperti ini, server layak diperiksa sebagai salah satu kemungkinan penyebab.
Tanda Server Bukan Penyebab
Bila TTFB sudah baik, tetapi LCP buruk karena foto besar atau INP buruk karena skrip, hosting yang lebih mahal belum tentu membantu. Hosting yang lebih cepat juga tidak otomatis menaikkan peringkat di Google.
Spa di contoh ini memang memakai paket hosting termurah, tetapi waktu respons servernya sudah dalam batas baik. Pindah hosting bisa ditunda, dan memperbaiki slider foto lebih masuk akal dikerjakan lebih dulu. Jadi, saran freelancer tadi belum tepat untuk kondisi ini.
Pilihan Upgrade Hosting bila Memang Diperlukan
Bila server atau kapasitas paket terbukti menjadi penyebab, ada tiga pilihan:
- Naik paket di penyedia yang sama: paling sederhana bila pemakaian sumber daya sudah melewati batas paket.
- Hosting WordPress terkelola: penyedia mengatur server dan cache, jadi kamu tidak perlu mengelolanya sendiri.
- VPS (Virtual Private Server, server virtual dengan sumber daya sendiri) atau cloud: lebih fleksibel, tetapi butuh orang yang mampu mengelola server.
Sebelum membeli paket baru, tanyakan lima hal ini kepada penyedia hosting:
- Lokasi server: apakah dekat dengan sebagian besar pengunjung website?
- Batas sumber daya: berapa kapasitas yang tersedia di paket itu?
- Cache sisi server: apakah tersedia untuk mempercepat pemuatan halaman?
- Backup dan pemulihan: apakah ada backup otomatis, dan bagaimana cara memulihkan website bila terjadi masalah?
- Bantuan migrasi: apakah penyedia membantu memindahkan website ke server baru?
Perlu CDN untuk Website Bisnis Lokal di Bali atau Jawa?
Tidak selalu. CDN (Content Delivery Network) menyimpan salinan file website di server di banyak kota agar lebih dekat ke pengunjung. Bila hampir semua pengunjung ada di Indonesia dan servernya di Indonesia atau negara tetangga, manfaatnya biasanya kecil.
CDN lebih berguna bila pengunjung tersebar, misalnya calon tamu spa dari luar negeri. CDN juga tidak memperbaiki foto yang berat atau skrip yang lambat.
Cara Pindah Hosting dengan Aman
Pindah hosting sebaiknya ditangani developer atau penyedia hosting. Bila alamat website tidak berubah, ikuti panduan Google tentang perpindahan hosting tanpa perubahan URL.
Intinya, website disiapkan dan diuji dulu di server baru, Googlebot tidak diblokir, dan verifikasi Search Console tetap aktif.
Panduan itu juga menyarankan menurunkan TTL DNS (Time to Live) sekitar seminggu sebelum pindah. Setelah DNS dialihkan dan website dipantau, server lama baru dimatikan saat tidak ada lagi pengunjung yang mengaksesnya.
Penurunan frekuensi crawl, yaitu kunjungan Googlebot, sesaat setelah pindah adalah hal normal. Pindah hosting yang dibarengi perubahan platform, desain, atau domain bisa ikut mengubah alamat halaman.
Dalam kondisi itu, siapkan pengalihan URL agar peringkat dan tautan yang ada tetap terjaga. Bila trafik website turun lebih dari wajar setelah pindah, cari penyebabnya dulu sebelum mengubah hal lain.
Siapa yang Menjaga Kecepatan, dan Seberapa Sering Dicek
Menjaga kecepatan butuh kerja sama pemilik bisnis, admin, pemasar, dan developer. Aktivitas sehari-hari seperti mengunggah foto dari HP, menambah widget, atau memasang kode iklan juga bisa memperlambat website.
Bagi Tugas antara Pemilik dan Developer
- Pemilik atau admin: mengecilkan foto sebelum diunggah, tidak menambah widget tanpa kebutuhan yang jelas, dan memeriksa laporan kecepatan setiap bulan.
- Developer atau penyedia hosting: mengatur cache server, tema, skrip, pembaruan besar, server, dan proses pindah hosting.
Cara Meminta Perbaikan kepada Developer
Agar developer cepat menemukan masalahnya, kirim alamat halaman yang bermasalah, tangkapan layar bagian atas dan bawah PageSpeed Insights, serta ukuran yang belum memenuhi batas baik.
Sebutkan juga targetnya: lolos tiga batas baik Core Web Vitals di HP, bukan skor 100.
Contohnya, pemilik spa di Jimbaran bisa mengirim pesan seperti ini:
LCP beranda di HP masih buruk karena slider. Mohon ganti slider dengan satu foto yang sudah dioptimalkan, jangan menunda pemuatan foto utama, dan pindahkan widget booking ke halaman paket.
Ukur Ulang setelah Perbaikan dan Setiap Bulan
Setelah memperbaiki, uji ulang dengan mengubah satu hal dalam satu waktu agar dampak tiap perubahan terlihat. Skor simulasi langsung berubah, sedangkan data pengunjung nyata butuh waktu karena memakai kunjungan 28 hari terakhir.
Fitur validasi perbaikan di laporan Core Web Vitals Search Console juga memantau hasil selama 28 hari.
Contoh website spa, skor simulasi membaik setelah slider dan feed Instagram dirapikan. Data pengunjung nyata baru diperiksa lagi sekitar sebulan kemudian.
Untuk pemantauan rutin, cek laporan Core Web Vitals minimal sebulan sekali dan setiap kali mengganti tema, menambah plugin atau widget, atau pindah hosting.
Jaga juga keamanannya dengan pembaruan rutin, kata sandi yang kuat, dan backup terjadwal. Website yang diretas bisa melambat dan sulit dipulihkan tanpa backup.
Setelah Website Cepat, Apa Selanjutnya?
Bila website sudah cepat tetapi kontak masih sepi, masalahnya mungkin ada di isi halaman atau jalur kontak, bukan kecepatan.
Periksa keduanya, karena dua hal itulah yang membuat website menghasilkan leads, yaitu calon klien yang benar-benar menghubungi, bukan sekadar ramai pengunjung.
Kecepatan juga hanya satu aspek teknis. Halaman yang belum masuk indeks, versi HP yang tidak lengkap, atau halaman yang hilang tetap bisa menghambat website di Google, meski waktu muatnya sudah cepat.
Ketiganya bisa diperiksa lewat checklist technical SEO dasar.
Penutup
Website lambat jarang beres dengan satu langkah, apalagi hanya dengan pindah hosting. Perbaikan yang berangkat dari data membuatmu tidak membayar paket yang belum dibutuhkan, dan hasilnya terasa oleh calon klien yang membuka website dari HP.
Ukur keberhasilannya dari pengalaman mereka, karena kecepatan hanyalah satu bagian dari rencana SEO yang menyeluruh.
Kalau kamu ingin tahu apakah halaman layananmu sudah lolos tiga batas baik di HP, kamu bisa mulai dari audit SEO dan Google Business Profile gratis.
Sumber:
Tinggalkan komentar