Mengupas hosting sampai tuntas — harga resmi, angka yang bisa dicek, dan siapa yang sebenarnya butuh.
Skenario yang hampir selalu sama. Situs terasa lambat, seseorang di forum menyarankan "hosting kamu jelek, pindah aja", lalu Anda membayar lebih mahal — dan situs tetap lambat. Uangnya hilang, masalahnya tidak.
Penyebabnya sederhana: kelambatan situs WordPress bisa datang dari empat lapisan yang berbeda, dan hanya satu di antaranya yang bisa diperbaiki dengan pindah hosting. Artikel ini menuntun Anda memisahkan keempatnya, mulai dari yang paling murah diperbaiki.
Ini pemisahan paling penting dalam seluruh proses, dan sayangnya paling sering dilewati.
TTFB (Time To First Byte) adalah waktu sejak browser mengirim permintaan sampai byte pertama jawaban diterima. Angka ini mencerminkan seberapa cepat server Anda merespons. Waktu muat total adalah berapa lama sampai seluruh halaman selesai tampil — dan itu sebagian besar urusan gambar, skrip, dan tema, bukan server.
Aturan praktisnya begini:
| Gejala | Kemungkinan penyebab | Perlu ganti hosting? |
|---|---|---|
| TTFB rendah, muat total lama | Gambar besar, tema berat, skrip pihak ketiga | Tidak |
| TTFB tinggi, halaman ringan | Server lambat, cache tidak aktif, PHP lama | Mungkin — periksa dulu cache |
| TTFB tinggi meski cache penuh | Keterbatasan sumber daya server | Kemungkinan besar ya |
| Lambat hanya saat trafik naik | Batas CPU atau memori paket Anda | Ya |
| Dashboard berat, depan normal | Plugin admin, database membengkak | Belum tentu |
Sebagai patokan kasar: TTFB di bawah 200 md tergolong baik, 200–500 md masih wajar, di atas 600 md perlu diperiksa. Pastikan lokasi pengujian dekat dengan mayoritas pengunjung Anda — menguji situs berserver Jakarta dari lokasi uji di Amerika akan memberi angka yang menyesatkan.
Kerjakan bagian ini lebih dulu. Berdasarkan pola yang paling umum, sebagian besar situs mendapat perbaikan yang terasa hanya dari langkah-langkah di bawah — tanpa mengganti apa pun di sisi server.
Ini penyebab nomor satu, dan yang paling mudah dibereskan. Foto langsung dari kamera atau ponsel sering berukuran 3–6 MB dan dimuat apa adanya. Kompres ke format WebP, atur ukuran tampilan sesuai kebutuhan asli, dan aktifkan lazy loading agar gambar di bawah layar tidak ikut dimuat di awal. Satu halaman dengan sepuluh gambar 4 MB tidak akan pernah cepat, di server semahal apa pun.
Bukan jumlahnya yang jadi masalah, melainkan apa yang dikerjakan masing-masing. Satu plugin page builder berat bisa lebih memberatkan daripada dua puluh plugin kecil. Yang perlu dicari: plugin yang memuat skrip di semua halaman padahal hanya dipakai di satu halaman, plugin statistik yang menulis ke database setiap kali ada kunjungan, dan dua plugin dengan fungsi tumpang tindih yang berjalan bersamaan. Query Monitor akan menunjukkan pelakunya dalam hitungan menit.
Plugin cache menyimpan versi jadi halaman Anda sehingga WordPress tidak perlu menyusun ulang setiap ada pengunjung. Untuk blog dan situs profil, efeknya besar. Dua catatan penting: jangan memasang dua plugin cache sekaligus — konflik dan tampilan rusak hampir pasti terjadi. Dan sadari bahwa halaman keranjang, checkout, serta area login memang tidak bisa di-cache; kalau situs Anda toko online, cache tidak akan menyelesaikan masalah di bagian-bagian itu.
Masih banyak situs berjalan di PHP versi lama karena tidak pernah ada yang menaikkannya. Naik ke versi PHP terbaru yang didukung tema dan plugin Anda sering memberi perbaikan yang terukur, dan biayanya nol. Uji di staging dulu — plugin lama kadang tidak kompatibel.
Setelah beberapa tahun, tabel WordPress terisi revisi pos yang menumpuk, komentar spam, opsi autoload dari plugin yang sudah lama dihapus, dan data sementara yang tidak pernah dibersihkan. Ini gejala klasik "dashboard berat tapi halaman depan normal". Bersihkan revisi, hapus data plugin lama, dan periksa ukuran opsi autoload.
Pixel iklan, widget chat, peta sematan, font eksternal, embed media sosial — masing-masing terlihat kecil, tapi setiap satu menambah permintaan ke domain lain yang kecepatannya di luar kendali Anda. Buka tab Network di peramban dan lihat berapa banyak domain berbeda yang dihubungi satu halaman Anda. Angkanya sering mengejutkan.
Kalau Anda sudah mengerjakan langkah dua, mengukur ulang, dan angkanya tetap buruk — sekarang baru masuk akal menyalahkan server. Pola berikut menunjukkan keterbatasan ada di sisi hosting dan tidak akan hilang dengan optimasi apa pun:
Satu faktor yang sering disalahpahami: lokasi server hanya berpengaruh besar pada permintaan yang tidak bisa di-cache. Untuk gambar dan file statis, CDN sudah menyelesaikan sebagian besar masalah jarak, karena file disajikan dari titik terdekat dengan pengunjung.
Tapi permintaan dinamis — menambah barang ke keranjang, memproses checkout, masuk ke area anggota — harus menempuh perjalanan penuh ke server asal setiap kali. Di sinilah jarak benar-benar terasa.
Kabar baiknya untuk pasar Indonesia: pilihan hosting dengan server dekat sekarang jauh lebih banyak dibanding beberapa tahun lalu. Selain hosting lokal, ada penyedia premium dengan pusat data Jakarta, dan region Singapura yang secara jaringan sangat dekat dengan Indonesia — latensinya biasanya di kisaran belasan sampai dua puluhan milidetik, bukan ratusan.
Setelah diagnosis selesai dan hasilnya menunjuk ke server, pertanyaan berikutnya bukan "mana yang terbaik" melainkan "mana yang sesuai beban dan anggaran saya".
Secara umum, TTFB di bawah 200 milidetik tergolong baik, 200 sampai 500 milidetik masih bisa diterima, dan di atas 600 milidetik menandakan ada yang perlu diperiksa. Tapi angka ini harus dibaca bersama lokasi alat ukurnya. Menguji situs berserver Jakarta dari lokasi uji di Amerika akan menghasilkan TTFB besar yang sama sekali tidak mencerminkan pengalaman pengunjung Indonesia Anda. Selalu pilih lokasi pengujian yang dekat dengan mayoritas audiens.
Sering membantu, tapi tidak selalu, dan kadang malah memperburuk. Plugin cache bekerja dengan menyimpan versi jadi dari halaman Anda, sehingga sangat efektif untuk konten statis seperti blog dan halaman profil. Untuk halaman yang memang tidak bisa di-cache — keranjang belanja, checkout, area login — plugin cache tidak membantu sama sekali. Memasang dua plugin cache sekaligus juga bisa menimbulkan konflik dan tampilan yang rusak.
Cara paling andal adalah memakai plugin Query Monitor di lingkungan staging, bukan di situs produksi. Query Monitor menampilkan kueri database yang lambat, permintaan HTTP eksternal, dan waktu eksekusi PHP per komponen, sehingga Anda bisa melihat langsung plugin mana yang paling banyak memakan waktu. Alternatif kasarnya adalah menonaktifkan plugin satu per satu di staging sambil mengukur ulang setiap kali.
Ketika TTFB tetap tinggi meski halaman sudah di-cache penuh, ketika Anda rutin menerima peringatan batas CPU atau proses yang dihentikan otomatis, ketika situs melambat justru saat trafik naik, atau ketika dashboard WordPress berat padahal plugin sudah dibersihkan. Pola-pola ini menunjukkan keterbatasan ada di sisi server, bukan di sisi situs Anda, dan tidak akan hilang dengan optimasi apa pun.
Tidak. Kalau penyebab lambatnya adalah tema berat, gambar besar yang tidak dioptimalkan, atau tumpukan plugin yang saling tumpang tindih, memindahkan situs hanya memindahkan masalah yang sama ke server yang lebih mahal. Perbaiki dulu sisi situs, ukur ulang, dan baru pertimbangkan pindah kalau angkanya tetap tidak membaik. Urutan ini juga menghemat uang Anda.
Situs WordPress yang lambat jarang punya satu penyebab tunggal. Yang biasanya terjadi adalah beberapa hal kecil menumpuk: gambar yang tidak dikompres, tiga plugin yang saling tumpang tindih, cache yang tidak pernah diaktifkan, dan paket hosting yang memang sudah tidak memadai — dan hanya yang terakhir yang bisa dibeli jalan keluarnya.
Urutannya penting, dan urutannya juga yang paling hemat: ukur, perbaiki yang gratis, ukur ulang, baru pertimbangkan pindah. Kalau setelah semua itu angkanya tetap buruk, Anda sudah punya bukti untuk memilih hosting baru dengan alasan yang jelas — bukan karena disuruh orang di forum.