Website Bisnis
Penyebab Website Lambat Diakses dan Cara Mengeceknya
Cara mengetahui penyebab website lambat diakses dengan PageSpeed Insights dalam sepuluh menit, arti angka di laporannya, dan hasil uji lima website nyata per November 2026.
Penyebab website lambat diakses hampir selalu ada di salah satu dari tiga tempat: server yang lama menjawab, file yang terlalu berat (paling sering gambar), atau kode CSS dan JavaScript yang harus selesai dimuat sebelum halaman boleh tampil. Untuk tahu yang mana, kamu tidak perlu membuka panel hosting. Cukup PageSpeed Insights, alat gratis dari Google, dan sekitar sepuluh menit membaca hasilnya.
Google menyarankan agar konten utama halaman (LCP) muncul dalam 2,5 detik pertama, dan menyebut metrik pengalaman halaman seperti ini selaras dengan yang dinilai sistem peringkat intinya. Saat saya menguji lima website dari portofolio dooha.id pada 1 November 2026, hanya satu yang memenuhi angka itu di simulasi HP. Website yang terasa cepat di laptop kantor dengan WiFi kencang bisa terasa lambat sekali bagi calon pelanggan yang membukanya dari HP di jalan.
Cara cek kecepatan website sendiri dengan PageSpeed Insights
Siapkan alamat halaman yang paling sering dibuka orang, biasanya beranda atau halaman layanan utama. Saat saya mengecek pada 1 November 2026, tampilan PageSpeed Insights berbahasa Inggris, jadi nama tombol di bawah ditulis persis seperti yang muncul di layar.
Langkah 1: Buka pagespeed.web.dev
Ketik pagespeed.web.dev di browser. Tidak perlu login atau membuat akun. Di tengah halaman ada kolom bertuliskan “Enter a web page URL”.
Langkah 2: Tempel alamat halaman lalu klik Analyze
Tempel alamat lengkap, misalnya https://namausahamu.com/, lalu klik tombol Analyze. Prosesnya sekitar setengah menit. Hasil yang pertama muncul adalah tab Mobile (simulasi HP), dan tab inilah yang perlu kamu perhatikan lebih dulu. Di pengujian kami, laporan menyebut simulasinya memakai HP Moto G Power dengan jaringan 4G yang diperlambat (“Slow 4G throttling”). Hasilnya memang lebih lambat daripada yang kamu rasakan di WiFi kantor, dan itu disengaja: Google memakai perangkat kelas menengah di jaringan seluler sebagai patokan.
Langkah 3: Baca bagian “Discover what your real users are experiencing”
Bagian paling atas berisi data pengunjung asli dari pengguna Chrome selama 28 hari terakhir. Kalau di sana tertulis “Core Web Vitals Assessment: Passed”, pengunjung nyatamu sudah mendapat pengalaman yang baik. Bila tertulis “Failed”, ada yang perlu dibenahi.
Di empat dari lima website yang kami uji, bagian ini hanya menampilkan “No Data”. Itu wajar untuk usaha kecil. Menurut Google, data ini baru muncul kalau jumlah kunjungan dari pengguna Chrome sudah cukup banyak. Kalau websitemu sudah terhubung ke Search Console, data serupa juga bisa dipantau lewat laporan Core Web Vitals di Search Console.
Langkah 4: Lihat skor Performance dan bagian METRICS
Di bawahnya ada bagian “Diagnose performance issues” dengan lingkaran skor Performance. Skor 90 ke atas dianggap baik, 50 sampai 89 perlu ditingkatkan, dan di bawah 50 buruk. Turun sedikit, di bagian METRICS, ada lima angka: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, dan Speed Index. Arti masing-masing ada di tabel pada bagian berikutnya.
Langkah 5: Cari baris “Est savings” di INSIGHTS dan DIAGNOSTICS
Bagian INSIGHTS dan DIAGNOSTICS berisi daftar masalah. Baris yang diberi keterangan “Est savings” (perkiraan penghematan) adalah petunjuk paling berguna, karena menyebut berapa kilobyte atau milidetik yang bisa dipangkas. Urutkan dari angka terbesar. Satu atau dua baris teratas biasanya sudah menunjuk penyebab utamanya.
Selesai mengecek, catat tanggal, skor, dan angka LCP di satu tempat, misalnya di catatan HP. Angka ini jadi pembanding setelah kamu atau developer mengubah sesuatu.
Membaca angka di laporan PageSpeed
Angka-angka di laporan lebih mudah dipahami kalau websitemu diibaratkan warung makan. TTFB adalah berapa lama sampai penjual menyahut “ya, sebentar”. FCP adalah saat sendok dan minuman pertama datang. LCP adalah saat piring utama sampai di meja, dan itulah momen pembeli merasa “pesanan saya sudah datang”. CLS adalah meja yang tiba-tiba digeser saat kamu mau meletakkan gelas, sehingga kamu salah tekan tombol. INP adalah berapa lama penjual menanggapi saat kamu memanggil lagi.
| Metrik di laporan | Yang diukur | Baik | Perlu ditingkatkan | Buruk |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Kapan konten terbesar, biasanya foto utama atau judul, selesai tampil | sampai 2,5 detik | 2,5 sampai 4 detik | lebih dari 4 detik |
| INP (Interaction to Next Paint) | Seberapa cepat halaman merespons klik atau ketukan | sampai 200 ms | 200 sampai 500 ms | lebih dari 500 ms |
| CLS (Cumulative Layout Shift) | Seberapa banyak tampilan bergeser saat dimuat | sampai 0,1 | 0,1 sampai 0,25 | lebih dari 0,25 |
| FCP (First Contentful Paint) | Kapan teks atau gambar pertama muncul | sampai 1,8 detik | 1,8 sampai 3 detik | lebih dari 3 detik |
| TTFB (Time to First Byte) | Berapa lama server mulai mengirim halaman | sampai 0,8 detik | 0,8 sampai 1,8 detik | lebih dari 1,8 detik |
Ambang ini mengikuti dokumentasi PageSpeed Insights. LCP, INP, dan CLS adalah angka Core Web Vitals. INP tidak ada di bagian METRICS dan hanya tampil di bagian data pengunjung asli. Di simulasi kamu akan melihat Total Blocking Time dan Speed Index, yang ikut menentukan skor Performance.
Hasil uji lima website portofolio kami
Supaya contohnya nyata, saya menguji lima website dari portofolio dooha.id dengan PageSpeed Insights tab Mobile pada 1 November 2026 pukul 14.16 sampai 14.22 WIB. Nama situsnya sengaja tidak saya tulis.
| Bidang usaha | Skor (HP) | LCP | Data pengunjung asli | Temuan dengan perkiraan penghematan terbesar |
|---|---|---|---|---|
| Jasa bordir | 89 | 2,2 detik | No Data | Gambar bisa dihemat sekitar 446 KiB, aturan cache browser, file yang menghambat tampilan 610 ms |
| Perusahaan teknik | 89 | 3,3 detik | No Data | File CSS dan JavaScript yang menghambat tampilan sekitar 1,8 detik |
| Les privat masuk PTN | 76 | 6,0 detik | No Data | Gambar bisa dihemat sekitar 815 KiB |
| Kontraktor dan sewa alat berat | 62 | 11,8 detik | No Data | File yang menghambat tampilan sekitar 2,3 detik, kerja browser 2,3 detik |
| Franchise barbershop | 60 | 9,4 detik | Failed: LCP 4,9 detik, TTFB 3,3 detik | Ukuran halaman sekitar 6 MB, aturan cache, file yang menghambat tampilan 1,7 detik |
Skor yang sama tidak berarti sama cepat. Website perusahaan teknik dan jasa bordir sama-sama mendapat 89, tapi LCP-nya selisih 1,1 detik. Penyebabnya pun berbeda di tiap website: website les privat hampir bersih dari masalah skrip dan penghematan terbesarnya ada di gambar, sedangkan website kontraktor tertahan oleh file CSS dan JavaScript.
Website barbershop satu-satunya yang punya data pengunjung asli. Di sana TTFB tercatat 3,3 detik pada persentil ke-75, artinya seperempat kunjungan menunggu lebih lama lagi sebelum server mulai mengirim halaman. Angka itu masuk kategori buruk. Buat kami sendiri, hasil ini jadi pengingat bahwa website yang terasa normal saat diserahkan tetap perlu dicek ulang setelah isinya bertambah.
Penyebab website lambat diakses dan tandanya di laporan
PageSpeed Insights tidak pernah menulis “hosting kamu lambat” atau “fotomu terlalu besar”. Yang muncul adalah istilah teknis berbahasa Inggris, dan masing-masing menunjuk ke penyebab yang cukup jelas.
| Penyebab | Tulisan yang muncul di laporan | Biasanya diperbaiki oleh |
|---|---|---|
| Server atau hosting lambat menjawab | TTFB di atas 0,8 detik, “Document request latency” | Pemilik website bersama penyedia hosting |
| Gambar terlalu besar atau formatnya lama | “Improve image delivery” | Pemilik website (sebelum upload) atau developer |
| Browser pengunjung harus mengunduh ulang file yang sama | “Use efficient cache lifetimes” | Developer atau plugin cache |
| CSS dan JavaScript menahan tampilan | “Render-blocking requests” | Developer |
| Plugin, tema, atau skrip yang tidak terpakai | “Reduce unused JavaScript”, “Reduce unused CSS” | Developer, kadang cukup pemilik website |
| Skrip dari layanan luar (chat, iklan, pelacak) | “3rd parties” | Pemilik website memutuskan mana yang perlu |
| Halaman memuat terlalu banyak isi | “Avoid enormous network payloads” | Pemilik website dan developer |
| Huruf (font) dimuat terlambat | “Font display” | Developer |
Dari semua baris itu, gambar adalah yang paling sering bisa diperbaiki pemilik usaha sendiri. Foto langsung dari HP atau kamera bisa berukuran beberapa megabyte, padahal yang tampil di layar HP hanya selebar beberapa ratus piksel. Kompres foto dan ubah ke format WebP sebelum diunggah.
Soal hosting, pendapat saya tidak berubah: yang murah dan cepat dipasang belum tentu bagus. Paket hosting paling murah umumnya berupa shared hosting, satu server dipakai bersama banyak akun, dan tandanya terlihat di TTFB. Kalau TTFB tinggi padahal halaman sudah ringan, masalahnya ada di server, dan mengecilkan gambar tidak akan banyak membantu. Biaya hosting yang layak memang perlu masuk hitungan sejak awal, seperti yang saya jabarkan di rincian komponen biaya website perusahaan.
Untuk website WordPress, plugin cache sering menjadi pembeda paling besar. Saya biasa memakai LiteSpeed Cache. Menurut halaman resminya di WordPress.org, fitur umum seperti optimasi gambar, minify CSS dan JavaScript, lazy-load, serta pembersih database bisa dipakai di server apa pun, sedangkan cache halaman otomatisnya hanya bekerja di server LiteSpeed atau OpenLiteSpeed, atau lewat CDN QUIC.cloud. Jadi tanyakan dulu ke penyedia hostingmu server apa yang dipakai sebelum memasangnya.
Keluhan website lambat juga pernah datang dari klien kami sendiri. Penyebabnya biasanya ada di dua baris tabel di atas: gambar yang diunggah berukuran besar dan plugin cache yang belum dipasang. Setelah menerima laporan seperti itu, kami menelusuri dulu penyebabnya, baru melakukan optimasi supaya websitenya kembali cepat saat diakses.
Lambat atau tidak bisa dibuka sama sekali?
Dua keluhan ini sering tercampur, padahal cara menanganinya berbeda. Website lambat tetap tampil, hanya butuh waktu lama. Website yang tidak bisa dibuka menampilkan pesan error, atau loading terus tanpa hasil.
Saya pernah mengalami yang kedua. Pada Juni 2026, sebuah VPS di Contabo tidak bisa diakses setelah diperpanjang. Status di panel penyedia tertulis “running”, tapi layanan web dan CyberPanel di dalamnya mati. Server baru pulih setelah di-restart dua kali dari rescue system. Pelajarannya, status “running” di dashboard hosting belum menjamin website bisa dibuka pengunjung.
Sebelum menyimpulkan websitemu lambat, lakukan tiga pengecekan cepat ini:
- Buka website dari HP dengan data seluler, bukan WiFi kantor. Kalau di HP lancar, kemungkinan masalahnya ada di jaringan kantor.
- Buka website lain yang besar. Kalau semuanya lambat, masalahnya ada di koneksimu.
- Jalankan PageSpeed Insights. Jika alat itu juga gagal membuka halamanmu, website kemungkinan sedang tidak bisa diakses, dan yang perlu dihubungi adalah penyedia hosting atau developer.
Yang bisa kamu perbaiki sendiri, dan yang sebaiknya diserahkan
Pemilik usaha yang memegang akses admin WordPress bisa mengerjakan beberapa perbaikan tanpa menyentuh kode:
- Kompres foto sebelum diunggah dan pakai format WebP. Untuk foto yang sudah terlanjur besar, fitur optimasi gambar di plugin cache bisa membantu.
- Nonaktifkan lalu hapus plugin yang sudah tidak dipakai. Sebelum menghapus, pastikan ada backup.
- Kurangi elemen berat di bagian atas beranda, seperti slider berisi banyak foto besar atau video yang otomatis diputar.
- Tinjau skrip pihak ketiga. Widget chat, pelacak iklan, dan sematan media sosial masing-masing menambah beban. Pertahankan yang benar-benar dipakai.
- Jalankan PageSpeed Insights lagi setelah setiap perubahan, lalu bandingkan dengan catatan pertama.
Yang sebaiknya diserahkan ke developer: TTFB yang tinggi (perlu pengecekan server atau pindah paket hosting), baris “Render-blocking requests” dan “Reduce unused JavaScript” (perlu mengatur urutan pemuatan file tanpa merusak tampilan), serta tema atau page builder yang memang berat. Perubahan di bagian ini bisa membuat tampilan berantakan kalau dikerjakan sambil menebak.
Kalau websitemu masih dalam tahap perencanaan, urutan memilih hosting, tema, dan isi halaman yang ringan sejak awal ada di panduan website untuk UMKM dari nol sampai tayang.
Kapan skor tidak perlu dikejar sampai 100
Skor PageSpeed adalah hasil simulasi di satu perangkat dan satu kondisi jaringan. Google sendiri menjelaskan bahwa skor bisa berubah dari satu pengujian ke pengujian berikutnya walau halamannya tidak diubah, karena kondisi jaringan dan perangkat penguji ikut berpengaruh. Jadi jangan panik kalau skormu turun beberapa poin di pengujian kedua.
Saran saya, pakai skor untuk menemukan masalah. Kalau LCP di simulasi HP sudah di bawah 2,5 detik dan data pengunjung asli (bila ada) berstatus Passed, sisa poin menuju 100 jarang sebanding dengan biaya dan risikonya. Mengejar 100 kadang berarti membuang fitur yang justru dipakai pelanggan, seperti tombol chat atau galeri foto.
Yang sering ditanyakan soal website lemot
Berapa skor PageSpeed yang dianggap bagus?
Menurut dokumentasi Google, skor 90 ke atas dianggap baik, 50 sampai 89 perlu ditingkatkan, dan di bawah 50 buruk. Untuk pemilik usaha, angka LCP di tab Mobile lebih penting daripada skornya: usahakan di bawah 2,5 detik.
Kenapa skor PageSpeed berubah padahal websitenya tidak diubah?
Skor dihitung dari simulasi, dan hasilnya dipengaruhi kondisi jaringan serta perangkat penguji saat itu. Perbedaan beberapa poin antar pengujian itu normal. Lihat trennya dari beberapa kali pengujian.
Kenapa bagian data pengguna nyata hanya menampilkan “No Data”?
Data pengguna nyata berasal dari pengguna Chrome selama 28 hari terakhir dan baru muncul kalau jumlah kunjungannya cukup. Website usaha kecil atau website yang baru tayang sering belum mencapai jumlah itu. Pakai data simulasi di bagian bawah laporan sebagai pegangan.
Apakah website lambat menurunkan posisi di Google?
Google menyatakan Core Web Vitals selaras dengan yang dinilai sistem peringkat intinya, tapi kecepatan hanya salah satu faktor di antara banyak faktor lain seperti relevansi isi. Website lambat lebih nyata merugikan karena pengunjung keburu menutup halaman. Kalau websitemu malah belum muncul sama sekali di Google, penyebabnya lain, dan cara memeriksanya ada di artikel penyebab website tidak muncul di Google.
Apakah pindah hosting membuat website lebih cepat?
Tidak selalu. Pindah hosting membantu kalau TTFB tinggi. Jika masalah utamanya gambar yang berat atau file CSS dan JavaScript yang menghambat tampilan, website akan tetap lambat di hosting mana pun sampai bagian itu dibenahi.
Setelah cek pertama: perbaiki sendiri atau minta bantuan
Mulailah dari satu halaman, yaitu beranda di tab Mobile. Catat skornya, angka LCP, dan dua baris “Est savings” terbesar. Kalau baris teratasnya soal gambar, kamu bisa mulai memperbaikinya hari ini. Jika yang muncul TTFB tinggi atau file yang menghambat tampilan, serahkan ke developer dengan membawa catatan itu supaya pekerjaannya terarah.
Bila tidak sempat mengerjakannya sendiri, dooha.id punya add-on optimasi kecepatan untuk sekali pengerjaan mempercepat waktu buka website, dan layanan perawatan Care di halaman Paket untuk website yang ingin dijaga terus setelah tayang. Kalau ada angka di laporan PageSpeed-mu yang membingungkan, jangan sungkan bertanya di kolom komentar.
