Cache Aktif, tetapi Website Tetap Lambat? Cara Menemukan Bottleneck yang Sebenarnya

Banyak pemilik website merasa sudah melakukan optimasi setelah memasang plugin cache atau mengaktifkan CDN. Namun, halaman tetap terasa lambat, terutama saat login, membuka halaman pencarian, atau mengakses dashboard. Ini bukan hal aneh: cache hanya mempercepat bagian tertentu dari proses, bukan seluruh jalur request.

Untuk menemukan penyebabnya, kita perlu melihat website sebagai rangkaian beberapa tahap: browser meminta halaman, DNS dan koneksi diproses, server menjalankan PHP, aplikasi membaca database, lalu hasilnya dikirim dan dirender oleh browser. Satu tahap yang lambat bisa membuat seluruh pengalaman ikut tersendat.

Cache tidak selalu bekerja pada semua halaman

Cache halaman paling efektif untuk konten publik yang sama bagi banyak pengunjung, seperti artikel, halaman kategori, atau landing page. Sebaliknya, halaman checkout, akun pengguna, dashboard, dan halaman yang memakai cookie tertentu biasanya perlu melewati aplikasi agar data tetap personal dan terbaru.

Di Nginx, misalnya, fastcgi_cache dapat menyimpan respons dari PHP-FPM. Namun, konfigurasi cache juga menentukan kapan sebuah request boleh mengambil hasil lama, kapan harus melewati cache, dan berapa lama respons disimpan. Header seperti Set-Cookie, Cache-Control, dan Vary juga dapat memengaruhi apakah respons dianggap layak untuk di-cache.

Artinya, tulisan “cache aktif” belum cukup sebagai diagnosis. Periksa respons aktual menggunakan DevTools browser atau perintah seperti:

curl -I https://contoh.com/halaman

Cari header seperti Age, X-Cache, atau header khusus dari CDN dan server Anda. Nama header berbeda-beda, tetapi tujuannya sama: memastikan apakah request benar-benar mendapat hasil cache atau tetap memanggil PHP.

Bedakan lambat sebelum server menjawab dan sesudahnya

Salah satu pemeriksaan paling berguna adalah melihat waktu tunggu sebelum byte pertama diterima. Waktu ini sering disebut Time to First Byte atau TTFB. Jika TTFB tinggi, perhatian sebaiknya diarahkan ke jaringan, CDN, web server, PHP-FPM, kode aplikasi, atau database.

Jika byte pertama sudah datang cepat tetapi halaman masih lama selesai, masalahnya kemungkinan berada pada ukuran HTML, gambar, JavaScript, font, atau proses rendering di browser. Dua kondisi ini membutuhkan pendekatan yang berbeda. Menambah RAM server tidak otomatis memperbaiki JavaScript yang terlalu berat, sebagaimana mengecilkan gambar tidak menyelesaikan query database yang menunggu beberapa detik.

PageSpeed Insights juga perlu dibaca dengan konteks. Laporan tersebut menggabungkan data lapangan dari pengguna nyata dan data lab dari Lighthouse. Data lab berguna untuk menguji perubahan secara terkontrol, sedangkan data lapangan menunjukkan pengalaman pengguna dalam kondisi perangkat dan jaringan yang beragam. Nilainya memang bisa berbeda.

Jangan hanya mengejar skor: pahami Core Web Vitals

Core Web Vitals saat ini mencakup LCP, CLS, dan INP. LCP mengukur kapan konten utama terlihat, CLS mengukur pergeseran tata letak yang tidak diharapkan, sedangkan INP menilai seberapa cepat halaman merespons interaksi pengguna seperti klik, ketuk, atau input.

Contohnya, halaman bisa memiliki LCP yang baik tetapi INP yang buruk. Pengunjung melihat halaman utama dengan cepat, tetapi tombol menu atau filter baru merespons setelah jeda panjang karena JavaScript sedang mengerjakan terlalu banyak tugas. Dalam kasus seperti ini, optimasi gambar saja tidak akan menyelesaikan masalah.

Untuk menemukan sumbernya, buka panel Performance di Chrome DevTools dan periksa long task, yaitu pekerjaan JavaScript yang memblokir thread utama terlalu lama. Periksa pula elemen LCP dan lihat apakah penyebabnya gambar besar, font yang terlambat dimuat, atau respons HTML yang belum siap.

PHP-FPM dan OPcache: dua lapisan yang sering terlupakan

Pada website PHP, setiap request dinamis dapat melibatkan pemuatan file, eksekusi framework atau CMS, pemanggilan plugin, dan akses database. PHP-FPM membantu mengelola proses PHP, tetapi jumlah worker yang terlalu sedikit dapat membuat request mengantre. Sebaliknya, worker yang terlalu banyak dapat menghabiskan RAM dan memicu swap atau pembunuhan proses oleh sistem operasi.

Periksa metrik seperti jumlah proses aktif, request yang menunggu, waktu eksekusi, dan penggunaan memori. Jangan langsung menaikkan jumlah worker tanpa melihat kapasitas RAM. Konfigurasi yang terlihat agresif di server besar bisa membuat server kecil semakin tidak stabil.

OPcache juga penting karena menyimpan hasil kompilasi bytecode PHP sehingga file PHP tidak perlu dikompilasi ulang pada setiap request. Pastikan OPcache aktif untuk proses web, bukan hanya untuk perintah PHP di terminal. Jika kapasitas memorinya terlalu kecil, cache dapat sering penuh dan manfaatnya berkurang.

Database lambat sering terlihat seperti server lambat

Halaman yang menunggu query database akan tampak seperti masalah hosting, padahal akar masalahnya bisa berada pada SQL. Query dengan filter, pengurutan, atau join tanpa index yang sesuai dapat memaksa database memeriksa terlalu banyak baris.

Gunakan EXPLAIN pada query yang dicurigai:

EXPLAIN SELECT id, title
FROM posts
WHERE status = 'publish'
ORDER BY published_at DESC
LIMIT 20;

Perhatikan apakah database melakukan full table scan, berapa banyak baris yang diperkirakan dibaca, dan index apa yang dipakai. Index dapat mempercepat pencarian, tetapi bukan berarti setiap kolom harus diberi index. Terlalu banyak index menambah penggunaan ruang dan membuat proses insert, update, serta delete lebih berat.

Di aplikasi CMS, periksa juga query yang berjalan berulang-ulang. Plugin analitik, pencarian, related posts, dan widget dinamis sering menambah beban tanpa terlihat jelas dari halaman depan.

Yang bisa dilakukan sekarang

1. Uji halaman publik dan halaman dinamis secara terpisah. Bandingkan halaman artikel, halaman pencarian, halaman login, dan dashboard.
2. Periksa header respons. Pastikan halaman yang seharusnya di-cache benar-benar menghasilkan cache hit.
3. Catat TTFB dan waktu total. Ini membantu membedakan masalah backend dari masalah aset frontend.
4. Audit PHP-FPM dan OPcache. Cari antrean worker, penggunaan RAM, serta cache opcode yang penuh.
5. Ambil query lambat. Gunakan log aplikasi atau slow query log, lalu analisis dengan EXPLAIN.
6. Uji satu perubahan pada satu waktu. Jangan mengaktifkan lima plugin optimasi sekaligus, karena Anda akan sulit mengetahui perubahan mana yang benar-benar membantu.

Apa artinya bagi kita?

Website cepat bukan hasil dari satu tombol, satu plugin, atau satu upgrade server. Performa adalah hasil kerja beberapa lapisan yang saling berhubungan. Cache membantu, CDN membantu, OPcache membantu, dan index database membantu—tetapi manfaatnya baru terasa jika diterapkan pada masalah yang tepat.

Mulailah dari pengukuran sederhana: halaman mana yang lambat, kapan kelambatan terjadi, dan tahap mana yang paling banyak memakan waktu. Setelah itu, ubah satu hal, ukur kembali, lalu dokumentasikan hasilnya. Pendekatan ini biasanya lebih aman dan lebih efektif daripada menambahkan optimasi secara acak.

Sumber & bacaan lebih lanjut

• Web Vitals — web.dev
• About PageSpeed Insights — Google for Developers
• Module ngx_http_fastcgi_module — Nginx
• PHP: OPcache Configuration — PHP Manual
• MySQL 8.4 Reference Manual: Optimization and Indexes
• Resource Timing — MDN Web Docs

– Rio Yotto @rioyotto