Mengira LSCache Sudah Aktif, Padahal Header x-litespeed-cache Selalu miss

Banyak orang menganggap begitu plugin LiteSpeed Cache (LSCache) terpasang dan statusnya aktif di dashboard WordPress, halaman otomatis di-cache. Anggapan ini wajar karena plugin menampilkan banyak opsi, tombol purge, dan pengaturan TTL, jadi kesannya semuanya sudah jalan. Masalahnya, situs tetap terasa lambat. Waktu header response dicek, x-litespeed-cache selalu miss atau bahkan tidak muncul sama sekali. Artinya setiap request tetap diproses PHP dan database dari nol.

Plugin hanya memberi instruksi, yang menyimpan cache adalah server

Ini bagian yang paling sering bikin salah paham. Plugin LSCache tidak menyimpan halaman. Tugasnya memberi tahu web server halaman mana yang boleh di-cache, berapa lama, dan kapan harus di-purge. Instruksi itu dikirim lewat header response khusus seperti x-litespeed-cache-control dan x-litespeed-tag. Yang benar-benar menyimpan salinan halaman dan menyajikannya ke pengunjung berikutnya adalah modul cache di LiteSpeed Web Server atau OpenLiteSpeed. Kalau server-nya bukan LiteSpeed, cache di level server belum diaktifkan oleh admin, atau instruksi dari plugin tidak pernah sampai, plugin tetap terlihat aktif tapi tidak ada yang disimpan. Di trafik kecil, efeknya sering tidak terasa. Halaman tetap terbuka, cuma agak lambat. Begitu trafik naik, setiap pengunjung memicu proses PHP baru. Dari sini biasanya muncul keluhan CPU penuh, limit proses akun tercapai, atau error 503. Di meja support, pola ini sering berujung pada pertanyaan pelanggan yang sama: "padahal LSCache sudah aktif, kok masih berat?" Jawabannya hampir selalu ada di header.

Membaca header x-litespeed-cache lewat curl dan DevTools

Cara paling cepat adalah meminta halaman yang sama dua kali dan melihat header-nya. Request pertama setelah purge memang wajar miss, karena cache belum terisi. Yang penting adalah request kedua.

BASH

# Ambil header saja, buang body. Jalankan dua kali berturut-turut.
curl -s -o /dev/null -D - 'https://example.com/' | grep -i -E '^(server|x-litespeed|cache-control|set-cookie|vary)'

Kita pakai -D - dengan request GET biasa, bukan -I. Alasannya, -I mengirim request HEAD, dan perilakunya kadang tidak sama persis dengan kunjungan browser.

TEXT

# contoh format output, request kedua
server: LiteSpeed
x-litespeed-cache: hit
x-litespeed-cache-control: public,max-age=604800

Nilai yang biasanya muncul:

hit berarti halaman disajikan dari cache publik.
miss berarti cache dicari tapi belum ada, lalu halaman dibuat ulang oleh PHP.
hit,private berarti disajikan dari private cache, yaitu cache khusus per pengunjung.

Kalau request kedua dan ketiga tetap miss, ada sesuatu yang membuat halaman tidak tersimpan. Kalau header-nya tidak ada sama sekali, masalahnya berada di lapisan yang lebih bawah. Di browser, buka DevTools, masuk ke tab Network, centang opsi untuk menonaktifkan cache browser, lalu reload. Klik request dokumen utama (biasanya baris paling atas) dan lihat bagian Response Headers. Satu hal penting: kalau kamu sedang login ke wp-admin di browser itu, hasilnya hampir pasti tidak mewakili pengunjung biasa. Cookie login membuat LSCache biasanya tidak menyajikan public cache. Untuk pengecekan, pakai jendela incognito atau curl.

Header tidak muncul sama sekali: cek lapisan server dan .htaccess dulu

Mulai dari header server. Kalau isinya Apache atau nginx, berarti request tidak dilayani LiteSpeed, dan cache LiteSpeed memang tidak akan bekerja. Ini sering terjadi di hosting yang ternyata tidak memakai LiteSpeed, atau di VPS yang menjalankan web server lain di depan. Kalau ada Cloudflare atau reverse proxy lain di depan, header server bisa diganti oleh proxy tersebut. Supaya tidak tertipu, uji langsung ke origin. Salah satu caranya memakai opsi --resolve di curl untuk mengarahkan domain ke IP server asli tanpa mengubah DNS. Kalau server-nya memang LiteSpeed tapi x-litespeed-cache tetap tidak muncul, ada dua penyebab yang umum. Pertama, cache belum diaktifkan di level server. Di beberapa setup, admin server harus menyalakan fitur cache dan menentukan lokasi penyimpanan cache lebih dulu, misalnya lewat plugin LiteSpeed di WHM atau konfigurasi server LiteSpeed. Caranya tergantung panel dan versi. Plugin LSCache di WordPress biasanya menampilkan peringatan kalau mendeteksi fungsi cache server tidak tersedia, jadi peringatan seperti itu jangan diabaikan. Kedua, rule di .htaccess tidak terbaca atau hilang. Plugin menulis blok seperti ini di .htaccess root situs:

APACHE

# BEGIN LSCACHE
<IfModule LiteSpeed>
RewriteEngine on
CacheLookup on
# rule lain yang ditulis plugin...
</IfModule>
# END LSCACHE

Isinya bisa berbeda per versi plugin. Yang perlu dicek: blok ini benar-benar ada, file bisa dibaca web server (ownership dan permission wajar), dan tidak ada rule lain di atasnya yang memotong request lebih dulu. Contohnya rule redirect atau rewrite dari plugin keamanan yang memakai flag [L] untuk semua request. Blok ini juga sering hilang setelah migrasi, restore backup, atau setelah .htaccess ditimpa plugin lain. Di OpenLiteSpeed, dukungan .htaccess lebih terbatas dibanding LiteSpeed Web Server. Perubahan rewrite rule umumnya baru terbaca setelah server di-restart. Jadi kalau .htaccess sudah benar tapi tidak ada efeknya, cek apakah ini OpenLiteSpeed dan apakah server sudah di-restart.

Kalau header x-litespeed-cache muncul tapi tidak pernah hit, berarti server mau mencari cache, tapi halamannya tidak pernah tersimpan atau setiap request dianggap varian yang berbeda. Cookie adalah penyebab paling sering. Ada dua sisi yang perlu dibedakan. Cookie di request, misalnya cookie login WordPress atau cookie keranjang WooCommerce, membuat LSCache sengaja tidak menyajikan public cache supaya data pribadi tidak bocor ke orang lain. Ini perilaku yang benar. Masalahnya ada di sisi lain: response yang mengandung Set-Cookie untuk semua pengunjung. Plugin chat, plugin popup, plugin analitik, atau kode tema yang memanggil session_start() bisa mengirim cookie baru di setiap halaman. Response seperti ini biasanya tidak disimpan sebagai public cache. Kalau curl tadi menampilkan set-cookie di halaman yang seharusnya statis untuk pengunjung anonim, itu tersangka pertama. Penyebab kedua adalah halaman yang ditandai tidak bisa di-cache. Lihat nilai x-litespeed-cache-control. Kalau isinya no-cache, berarti plugin atau kode lain memutuskan halaman ini tidak boleh disimpan. Bisa karena halaman masuk daftar pengecualian, karena request-nya POST, atau karena ada plugin lain yang memanggil fungsi untuk menandai halaman sebagai non-cacheable. Untuk tahu alasannya, aktifkan debug log di pengaturan plugin LSCache sebentar, buka halaman sebagai pengunjung anonim, lalu baca log-nya. Matikan lagi setelah selesai, karena log ini bisa cepat membesar. Penyebab ketiga adalah query string dan varian. Setiap URL dengan query string berbeda biasanya dianggap entri cache yang berbeda. Trafik dari iklan atau newsletter yang membawa parameter tracking unik per klik akan selalu miss, karena setiap URL baru bagi cache. LSCache punya opsi untuk mengabaikan parameter tertentu saat mencari cache. Cek di pengaturan plugin versi yang dipakai. Header Vary juga bekerja dengan logika yang mirip. Vary memberi tahu cache bahwa satu URL punya beberapa versi tergantung nilai tertentu dari request, misalnya cookie tertentu atau jenis perangkat. LiteSpeed memakai x-litespeed-vary untuk ini. Kalau ada plugin yang menambahkan vary berdasarkan cookie yang nilainya unik per pengunjung, setiap orang mendapat varian sendiri. Secara teknis cache tersimpan, tapi hampir tidak pernah dipakai ulang. Gejalanya sama dengan selalu miss. Opsi cache terpisah untuk mobile juga menambah varian, jadi saat menguji dengan curl, pakai user agent yang konsisten.

Urutan pengecekan sebelum bilang cache sudah jalan

Supaya tidak berputar-putar, urutan pengecekan ini biasanya cukup:

Pastikan request dilayani LiteSpeed. Lihat header server, dan uji ke origin kalau ada proxy di depan.
Pastikan header x-litespeed-cache muncul. Kalau tidak muncul, cek aktivasi cache di level server, blok LSCACHE di .htaccess, dan restart kalau memakai OpenLiteSpeed.
Request halaman yang sama dua sampai tiga kali sebagai pengunjung anonim. Hasil yang diharapkan adalah miss lalu hit.
Kalau tetap miss, cek set-cookie, nilai x-litespeed-cache-control, query string, dan vary. Aktifkan debug log plugin sebentar untuk melihat alasannya.
Setelah ada perubahan, purge cache lalu uji ulang dari langkah 3.

Satu catatan soal ekspektasi. hit di halaman depan belum berarti seluruh situs aman. Halaman checkout, keranjang, dan akun memang seharusnya tidak di-cache. Yang perlu dipastikan adalah halaman yang paling banyak dikunjungi pengunjung anonim, seperti beranda, artikel, kategori, dan produk. Jadi, status aktif di dashboard plugin bukan bukti apa-apa. Buktinya ada di header response. Biasakan menjalankan curl dua kali setiap selesai memasang plugin, migrasi situs, atau menambah plugin baru. Kalau hasilnya tetap miss, cari siapa yang mengirim cookie atau menandai halaman no-cache, sebelum menyimpulkan servernya yang kurang kuat.