Anda sudah mengompresi gambar, tetapi situs WordPress tetap terasa lambat. Kemungkinan besar masalahnya bukan di gambar — melainkan di TTFB (Time to First Byte): waktu yang dibutuhkan server untuk menghasilkan byte pertama halaman. Bila TTFB tinggi, setiap pengunjung harus menunggu server “berpikir” sebelum apa pun tampil.
Daftar Isi
- Jawaban Singkat
- Diagnosis: Di Mana Waktu Habis?
- Persiapan
- Langkah 1: Pastikan Fondasi Server Sehat
- Langkah 2: Aktifkan Page Cache
- Langkah 3: Tambahkan Object Cache untuk Pengguna Login dan Kueri Berulang
- Langkah 4: Bersihkan Database dari Beban yang Tidak Perlu
- Langkah 5: Audit Plugin dengan Metode Nonaktifkan
- Verifikasi Hasil
- Troubleshooting Lanjutan
- FAQ
- Kesimpulan
Jawaban Singkat
Bedakan dulu: TTFB tinggi berarti server lambat menghasilkan halaman (PHP, database, atau plugin berat). Unduhan lambat setelah byte pertama berarti masalah aset (gambar, CSS, JS, atau jaringan). Untuk TTFB, obatnya adalah mengurangi pekerjaan per permintaan: cache halaman, object cache, kueri yang efisien, dan PHP yang sehat — bukan sekadar mengecilkan gambar.
Diagnosis: Di Mana Waktu Habis?
| Gejala | Kemungkinan penyebab | Pemeriksaan |
|---|---|---|
| Semua halaman lambat, termasuk yang sederhana | Server kekurangan sumber daya / PHP-FPM bermasalah | Beban CPU/RAM, status PHP-FPM |
| Hanya halaman tertentu yang lambat | Kueri/plugin spesifik di halaman itu | Nonaktifkan plugin halaman itu, periksa kueri lambat |
| Lambat hanya saat tidak login / pertama kali | Tidak ada page cache untuk pengunjung anonim | Periksa header cache dan plugin cache |
| Lambat setelah trafik naik | Tidak ada object cache; tiap permintaan menghantam database | Pantau Threads_connected dan beban MySQL |
Ukur sebelum mengubah apa pun: catat TTFB beranda, satu artikel, dan wp-admin (pengukuran kasar lewat alat browser sudah cukup untuk perbandingan sebelum–sesudah). Tanpa angka awal, Anda tidak tahu apakah perubahan benar-benar membantu.
Persiapan
- Backup database dan file sebelum mengubah konfigurasi cache.
- Ubah satu hal dalam satu waktu dan ukur lagi — mengubah lima hal sekaligus membuat Anda tidak tahu mana yang berhasil.
- Uji di jendela privat agar cache browser tidak mengaburkan hasil.
Langkah 1: Pastikan Fondasi Server Sehat
Cache tidak menyelamatkan server yang kehabisan sumber daya. Periksa:
free -h
sudo systemctl status php8.3-fpm nginx mysqlPastikan versi PHP yang dipakai masih didukung dan OPcache aktif (OPcache menyimpan bytecode PHP yang sudah dikompilasi sehingga PHP tidak mengompilasi ulang setiap permintaan). Bila PHP-FPM sering mencapai pm.max_children, atasi dulu kapasitas worker sebelum menyalahkan plugin.
Langkah 2: Aktifkan Page Cache
Page cache menyimpan HTML jadi dari halaman yang sudah dirender, sehingga permintaan berikutnya dari pengunjung anonim tidak perlu menjalankan PHP dan MySQL sama sekali. Pilih satu mekanisme dan pastikan ia benar-benar aktif:
- Plugin cache WordPress yang menulis file HTML statis, atau
- FastCGI cache di Nginx untuk situs tanpa plugin cache.
Jangan menjalankan keduanya secara bersamaan tanpa memahami interaksinya — cache ganda yang tidak sinkron menghasilkan halaman usang yang membingungkan. Verifikasi dengan memeriksa header respons: halaman yang ter-cache seharusnya menunjukkan status cache HIT pada permintaan kedua.
Pengecualian penting: halaman yang dipersonalisasi (keranjang, akun, wp-admin) tidak boleh di-cache untuk pengunjung yang login. Konfigurasi cache yang benar selalu mengecualikan cookie login dan area admin.
Langkah 3: Tambahkan Object Cache untuk Pengguna Login dan Kueri Berulang
Page cache tidak membantu pengguna yang login atau halaman dinamis. Di sinilah object cache (misalnya Redis) berperan: ia menyimpan hasil kueri dan objek WordPress di memori, sehingga permintaan berulang tidak perlu kembali ke database. Dampaknya paling terasa di situs dengan banyak kueri per halaman dan trafik login yang tinggi.
Setelah mengaktifkan object cache, pantau memori Redis dan pastikan ia tidak memakan RAM yang dibutuhkan MySQL dan PHP-FPM. Cache yang kekurangan memori akan mengusir entri terus-menerus dan manfaatnya hilang.
Langkah 4: Bersihkan Database dari Beban yang Tidak Perlu
Database WordPress membengkak secara diam-diam: revisi posting, komentar spam, transient kedaluwarsa, dan data plugin yang sudah dihapus. Sebelum membersihkan:
- Backup database.
- Bersihkan lewat alat tepercaya atau perintah yang Anda pahami — jangan menjalankan DELETE mentah ke tabel yang tidak Anda kenali.
- Periksa tabel terbesar terlebih dahulu; satu tabel plugin yang membengkak sering menjelaskan separuh kelambatan.
Pembersihan yang agresif tanpa backup adalah cara tercepat mengubah situs lambat menjadi situs rusak.
Langkah 5: Audit Plugin dengan Metode Nonaktifkan
Plugin adalah penyebab TTFB tinggi yang paling sering diremehkan. Nonaktifkan plugin yang tidak esensial satu per satu dan ukur TTFB setelah tiap penonaktifan. Plugin yang layak dicurigai:
- Plugin statistik/keamanan yang menjalankan kueri di setiap halaman.
- Plugin page builder berat yang dipakai di sedikit halaman tetapi dimuat di semua halaman.
- Plugin yang memanggil API eksternal tanpa timeout yang wajar — satu API lambat bisa menahan seluruh halaman.
Verifikasi Hasil
Perbaikan berhasil bila TTFB beranda dan artikel turun secara konsisten (bukan hanya sekali), halaman yang di-cache menunjukkan HIT, dan beban MySQL menurun saat trafik yang sama. Uji juga saat login dan saat logout — keduanya harus membaik atau setidaknya tidak memburuk.
Troubleshooting Lanjutan
| Situasi | Langkah berikutnya |
|---|---|
| TTFB turun, tetapi situs tetap terasa lambat | Masalahnya kini di aset (gambar/CSS/JS) atau jaringan — optimalkan aset dan periksa dari lokasi pengunjung |
| Cache aktif, tetapi TTFB tidak berubah | Pastikan cache benar-benar HIT; kemungkinan aturan pengecualian terlalu luas |
| Halaman usang tampil setelah update | Periksa aturan purge cache saat posting diperbarui; purge manual setelah perubahan penting |
| Situs cepat saat sepi, lambat saat ramai | Fokus ke object cache dan kapasitas worker PHP-FPM, bukan ke gambar |
FAQ
Apakah page cache cukup tanpa object cache?
Untuk situs yang mayoritas pengunjungnya anonim, page cache memberi dampak terbesar. Object cache menjadi penting saat banyak pengguna login atau halaman sangat dinamis.
Kenapa TTFB wp-admin tetap tinggi?
Karena wp-admin sengaja tidak di-cache. TTFB admin yang tinggi menandakan masalah PHP/database/plugin, bukan masalah cache halaman.
Apakah menaikkan RAM selalu mempercepat WordPress?
Tidak. RAM membantu bila kekurangan memori memang menjadi hambatan. Bila penyebabnya kueri buruk atau plugin berat, RAM tambahan hanya memberi ruang bagi masalah yang sama untuk berjalan lebih lama.
Kesimpulan
TTFB tinggi adalah pesan dari server: “saya terlalu banyak bekerja per permintaan.” Kurangi pekerjaan itu dengan fondasi PHP yang sehat, page cache untuk pengunjung anonim, object cache untuk pekerjaan berulang, database yang bersih, dan plugin yang diaudit. Ukur sebelum dan sesudah setiap perubahan — karena optimasi yang tidak diukur hanyalah tebakan yang terdengar teknis.