Penyebab website lambat hampir selalu berada di salah satu dari tiga lapisan: kueri basis data yang tidak berindeks, cache yang belum aktif, atau berkas gambar dan skrip yang terlalu berat. Menaikkan spesifikasi server biasanya bukan jawabannya — dan sering hanya menunda gejalanya.
Keluhan yang datang biasanya tidak spesifik: situs terasa lambat. Tanpa angka, perbaikannya jadi menebak — dan menebak pada infrastruktur berarti mengeluarkan biaya untuk hal yang belum tentu penyebabnya.
Artikel ini menyusun penyebabnya berdasarkan seberapa sering kami temui, beserta cara memastikan mana yang berlaku di situs Anda sebelum mengubah apa pun.
Pisahkan dulu: lambat di server, atau lambat di browser
Ini langkah pertama yang paling sering dilewat, padahal ia membelah masalahnya jadi dua wilayah yang perbaikannya sangat berbeda.
Buka alat pengembang browser, tab Network, muat ulang halaman. Perhatikan permintaan pertama — dokumen HTML-nya. Kolom waiting atau TTFB menunjukkan berapa lama server berpikir sebelum mengirim byte pertama. Kalau angka itu di bawah 300 milidetik, server Anda tidak lambat; masalahnya di berkas yang dimuat sesudahnya.
Kalau TTFB tinggi — di atas satu detik, misalnya — masalahnya di dalam server, dan mengecilkan gambar tidak akan menolong sama sekali.
Kueri database lambat: penyebab nomor satu
Dari yang kami tangani, query database lambat adalah penyebab tunggal terbesar untuk TTFB tinggi. Gejalanya khas: situs cepat saat sepi, melambat saat ramai, dan grafik CPU terlihat wajar sepanjang waktu.
Cara memastikannya: nyalakan log kueri lambat. Pada MySQL, `slow_query_log` dengan `long_query_time` disetel 1 detik sudah cukup untuk menangkap tersangka utama. Biarkan berjalan sehari pada beban normal, lalu ringkas hasilnya dengan `mysqldumpslow` — yang dicari bukan kueri paling lambat, tetapi kueri yang total waktunya paling besar. Kueri 50 milidetik yang dijalankan tiga ribu kali per halaman lebih merugikan daripada satu kueri 2 detik.
Perbaikannya bertingkat. Tambahkan indeks pada kolom yang dipakai di `WHERE` dan `JOIN`. Periksa rencana eksekusi dengan `EXPLAIN` dan cari pemindaian tabel penuh. Untuk aplikasi yang kodenya tidak bisa diubah, indeks saja sering sudah menyelesaikan sebagian besarnya.
Cache belum aktif, atau aktif tapi tidak bekerja
Kasus cache belum aktif lebih sering terjadi daripada yang diperkirakan orang, termasuk di situs yang plugin cache-nya terpasang. Terpasang dan bekerja adalah dua hal berbeda.
Cara memeriksanya cepat: buka halaman dua kali dan bandingkan TTFB-nya. Kalau permintaan kedua sama lambatnya, cache tidak menyajikan apa pun. Pada WordPress, periksa juga apakah header respons membawa penanda cache — plugin yang benar biasanya menambahkannya.
Ada tiga lapisan cache yang berbeda dan sering dikira satu. Cache halaman menyimpan HTML jadi. Cache objek menyimpan hasil kueri, dan inilah yang menolong halaman yang dipersonalisasi seperti keranjang atau dasbor. Cache opcode menyimpan hasil kompilasi PHP — pastikan OPcache menyala, karena tanpa itu setiap permintaan mengompilasi ulang seluruh kode.
Website lambat padahal spesifikasi server besar
Kondisi website lambat padahal spesifikasi server besar adalah tanda paling jelas bahwa masalahnya bukan kapasitas. Server 16 GB yang lambat biasanya lambat karena konfigurasinya tidak memakai kapasitas itu.
Yang sering ditemukan: `innodb_buffer_pool_size` masih pada nilai bawaan beberapa ratus megabita di server dengan memori belasan gigabita. Basis data membaca dari disk terus-menerus padahal seluruh datanya bisa masuk memori. Satu perubahan konfigurasi dan satu kali restart mengubah situs secara drastis.
Hal serupa berlaku untuk jumlah proses PHP-FPM. Terlalu sedikit membuat permintaan mengantre meski CPU menganggur; terlalu banyak membuat memori habis dan sistem memakai swap. Keduanya terasa sebagai lambat, dan keduanya soal konfigurasi.
Berkas terlalu berat dan terlalu banyak
Kalau TTFB Anda sudah baik tetapi halaman tetap terasa lama muncul, penyebabnya ada di sini. Ini juga wilayah yang paling mudah diperbaiki tanpa menyentuh server.
- Gambar yang diunggah pada ukuran asli kamera lalu dikecilkan lewat CSS — kompres dan sajikan pada ukuran tampilnya.
- Format lama: JPG dan PNG masih dipakai padahal WebP menghemat cukup banyak pada kualitas yang sama.
- Gambar tanpa `width` dan `height`, yang menyebabkan tata letak bergeser saat memuat.
- Font yang dimuat dari domain lain, menambah satu putaran koneksi sebelum teks tampil.
- Skrip pihak ketiga — pelacak, obrolan, peta — yang memblokir tampilan awal.
- CSS dan JavaScript yang dimuat di semua halaman padahal hanya dipakai di satu halaman.
Cara mempercepat loading website: urutan yang paling hemat
Kalau harus memilih urutan, ini yang memberi hasil terbesar per jam kerja. Cara mempercepat loading website yang efektif hampir selalu dimulai dari hal yang gratis.
Pertama, aktifkan cache di semua tiga lapisan dan pastikan benar-benar bekerja. Kedua, nyalakan kompresi respons — Brotli atau gzip. Ketiga, kompres gambar dan konversi ke format modern. Keempat, benahi indeks basis data berdasarkan log kueri lambat. Kelima, sesuaikan konfigurasi memori basis data dan jumlah worker.
Baru setelah lima langkah itu, pertimbangkan CDN untuk pengunjung yang jauh dari server, dan terakhir barulah menaikkan spesifikasi. Urutan yang dibalik — menaikkan spesifikasi lebih dulu — adalah cara termahal mendapat perbaikan paling kecil.
Yang perlu diukur ulang setelah perbaikan
Setiap perubahan sebaiknya diukur, bukan dirasakan. Perasaan cepat setelah bekerja berjam-jam pada satu masalah bukan data yang bisa dipercaya.
Catat TTFB dan waktu muat penuh sebelum dan sesudah, pada halaman yang sama dan jam yang sama. Untuk situs dengan trafik nyata, ukur juga pada jam sibuk — perbaikan yang terlihat besar di jam sepi kadang tidak berpengaruh saat beban tinggi.
Kalau setelah semua langkah di atas situs masih lambat pada beban tinggi, di titik itu barulah menambah kapasitas menjadi keputusan yang berdasar. Bedanya, sekarang Anda tahu apa yang dibayar.
Kapan lambatnya memang soal kapasitas
Setelah cache, indeks, dan konfigurasi memori dibereskan, ada sisa kasus di mana servernya memang tidak cukup. Tandanya bisa diperiksa dan tidak perlu ditebak.
Beban rata-rata yang konsisten melebihi jumlah inti prosesor pada jam sibuk adalah tanda paling jelas. Angka 4,0 pada server dua inti berarti dua kali lipat pekerjaan yang bisa ditangani, dan setiap permintaan mengantre. Tanda kedua: swap terpakai terus-menerus, bukan sesekali — itu berarti memori benar-benar habis dan sistem membaca dari disk untuk hal yang seharusnya di memori.
Tanda ketiga lebih halus dan sering terlewat: waktu tunggu I/O tinggi pada keluaran `top` di kolom `wa`. Itu menunjukkan prosesor menganggur sambil menunggu disk. Pada VPS, penyebabnya bisa disk yang lambat atau tetangga yang sibuk — dan yang kedua tidak bisa diperbaiki dari dalam server.