Nginx FastCGI Cache: WordPress di VPS Ringan Tanpa Plugin Cache

Ada satu hal yang sering terlupa setiap kali kita menaikkan spesifikasi VPS: halaman WordPress tetap dirakit dari nol pada setiap kunjungan. PHP dijalankan, database ditanya berkali-kali, tema dan plugin dirender, baru HTML-nya dikirim ke browser. Untuk satu pengunjung tidak terasa. Begitu lima puluh orang datang bersamaan — biasanya setelah tautan dibagikan di grup WhatsApp — server mulai menghitung mundur, dan CPU naik ke angka yang bikin kita membuka panel hosting sambil menahan napas.

Padahal jawabannya tidak selalu “tambah RAM”. Sebagian besar halaman WordPress itu isinya sama untuk semua pengunjung. Kalau hasilnya sudah pernah dibuat, kenapa harus dirakit ulang?

Di sinilah fastcgi cache nginx bekerja: Nginx menyimpan hasil render PHP sebagai file HTML, lalu menyajikannya langsung tanpa menyentuh PHP-FPM dan database. Artikel ini membahas pemasangannya di VPS sendiri, lengkap dengan aturan halaman mana yang tidak boleh di-cache — bagian yang paling sering dilewatkan orang, dan justru paling berbahaya kalau salah.

Kenapa cache halaman mengalahkan tambah RAM

Alur normal sebuah permintaan WordPress seperti ini: Nginx menerima request, meneruskannya ke PHP-FPM, PHP mengeksekusi kode tema dan plugin, PHP bertanya ke MariaDB, hasilnya dirangkai jadi HTML, lalu dikirim balik. Satu halaman bisa berarti puluhan query dan puluhan file PHP yang harus dikompilasi.

Dengan cache halaman, langkah kedua sampai kelima dilewati. Nginx cukup mengirim file HTML yang sudah tersimpan. Database dan PHP bahkan boleh mati sebentar tanpa pengunjung sadar — Nginx tetap bisa menyajikan versi cache-nya. Itu sebabnya situs bercache terasa “tidak bisa dijatuhkan” oleh lonjakan trafik.

Yang perlu diingat: cache halaman tidak menggantikan RAM yang kurang untuk aplikasi yang memang butuh memori. Ia menghilangkan pekerjaan yang berulang. Dua hal berbeda, dan sering tertukar.

Sebelum mulai: cek dua versi ini

Sebelum menyentuh konfigurasi, pastikan dua hal:

Nginx — versi stabil terakhir saat artikel ini ditulis adalah 1.30.6, sedangkan jalur mainline ada di 1.31.8 (halaman unduh resmi nginx.org). Semua direktif di artikel ini sudah lama ada, jadi versi 1.24 ke atas aman.
PHP — pakai 8.5.12 atau 8.4.27. Keduanya dirilis 22 Oktober 2026. Di hari yang sama tim PHP juga merilis 8.3.36 dan 8.2.35; keempatnya membawa perbaikan dua GitHub Security Advisory di Core (state corruption saat bailout) — alasan yang cukup untuk apt upgrade walau kita tidak mengejar fitur baru. Perhatikan juga: PHP 8.2 mencapai akhir masa dukungan keamanan pada 31 Desember 2026, jadi kalau VPS kita masih di 8.2, ini waktu yang tepat untuk naik.

Kalau nginx -v dan php -v sudah menunjukkan angka di atas, kita lanjut.

Cara kerja FastCGI cache secara singkat

Anggap PHP-FPM sebagai koki dan Nginx sebagai pelayan. Tanpa cache, setiap tamu memesan, koki memasak dari awal, pelayan mengantar. Dengan cache, pelayan menyimpan satu porsi contoh: tamu berikutnya yang memesan menu sama langsung dilayani dari rak, koki tidak perlu bergerak.

Tiga istilah yang akan kita pakai:

keys_zone — memori kecil untuk menyimpan indeks cache (nama zona + ukuran, misal 100m). Ini bukan tempat isi halaman, hanya daftar isinya.
max_size — batas ukuran file cache di disk.
inactive — berapa lama sebuah entri boleh tidak diakses sebelum dibuang.

Langkah 1: Siapkan folder cache

Buat direktori cache dan beri hak akses ke user web server:


sudo mkdir -p /var/cache/nginx/wpcache
sudo chown -R www-data:www-data /var/cache/nginx/wpcache

Kalau VPS kita memakai user nginx (bukan www-data), sesuaikan. Salah user di sini adalah penyebab paling umum cache yang tidak pernah terisi, tanpa pesan error apa pun di log.

Langkah 2: Tambahkan zona cache di blok server

Buka file virtual host WordPress, misalnya /etc/nginx/sites-available/donnebanget.com, lalu tambahkan di dalam blok server:


fastcgi_cache_path /var/cache/nginx/wpcache levels=1:2
                   keys_zone=WPCACHE:100m
                   max_size=1g inactive=60m
                   use_temp_path=off;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;

Penjelasan singkat:

levels=1:2 menyebar file ke subfolder supaya satu direktori tidak berisi puluhan ribu file.
keys_zone=WPCACHE:100m menyediakan 100 MB memori untuk indeks; cukup untuk ratusan ribu halaman.
max_size=1g membatasi isi disk. Untuk blog, 500 MB–1 GB sudah lebih dari cukup.
fastcgi_ignore_headers memaksa Nginx mengabaikan header Set-Cookie dan Cache-Control dari PHP yang bisa membatalkan cache.

Langkah 3: Tentukan halaman yang TIDAK boleh di-cache

Ini bagian yang menentukan situs kita aman atau berantakan. Kalau halaman login, keranjang, atau dashboard ikut ter-cache, pengunjung bisa melihat halaman milik orang lain. Kita pakai satu variabel $skip_cache:


set $skip_cache 0;

if ($request_method = POST) { set $skip_cache 1; }
if ($query_string != "")   { set $skip_cache 1; }

# Area admin, login, feed, sitemap, cron, xmlrpc
if ($request_uri ~* "/wp-admin/|/wp-login.php|/xmlrpc.php|wp-cron.php|/wp-json/|^/feed|sitemap.*\.(xml|xsl)") {
    set $skip_cache 1;
}

# Pengunjung yang login atau baru berkomentar
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in|woocommerce_items_in_cart|wp_woocommerce_session") {
    set $skip_cache 1;
}

Aturan query string ($query_string != "") memang membuat URL pencarian dan parameter pelacakan selalu lolos ke PHP. Sedikit lebih boros, tapi jauh lebih aman — dan halaman yang paling sering dibuka pengunjung biasanya URL bersih tanpa parameter.

Langkah 4: Aktifkan cache di blok PHP

Di dalam location ~ \.php$, tambahkan:


fastcgi_cache WPCACHE;
fastcgi_cache_valid 200 301 302 60m;
fastcgi_cache_valid 404 1m;
fastcgi_cache_use_stale error timeout updating http_500 http_503;
fastcgi_cache_lock on;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
add_header X-FastCGI-Cache $upstream_cache_status always;

Perhatikan always di baris terakhir. Tanpa itu, header penanda cache hanya muncul pada kode status tertentu, dan kita akan bingung sendiri saat menguji. fastcgi_cache_lock on mencegah sepuluh request bersamaan merender halaman yang sama sepuluh kali — efeknya sering disebut thundering herd.

Uji konfigurasi, lalu muat ulang:


sudo nginx -t
sudo systemctl reload nginx

Selalu reload, bukan restart, supaya koneksi yang sedang berjalan tidak terputus.

Langkah 5: Buktikan cache benar-benar bekerja

Jangan percaya “sepertinya lebih cepat”. Minta statusnya langsung:


curl -sI https://donnebanget.com/ | grep -i x-fastcgi-cache

Tiga nilai yang akan kita lihat:

MISS pada request pertama — halaman baru saja masuk cache.
HIT pada request kedua dan seterusnya — inilah yang kita mau.
BYPASS saat membuka /wp-admin/ — bukti aturan skip bekerja.

Kalau hasilnya selalu MISS, periksa dua hal: folder cache harus writable oleh user Nginx, dan tidak ada Set-Cookie yang lolos karena fastcgi_ignore_headers belum terpasang.

Langkah 6: Bersihkan cache saat konten berubah

Nginx tidak tahu kapan kita menerbitkan artikel baru. Tanpa pembersihan, pengunjung bisa melihat versi lama sampai 60m habis. Ada dua cara:

Manual dan paling jujur: sudo rm -rf /var/cache/nginx/wpcache/* lalu sudo systemctl reload nginx. Cocok kalau kita jarang mengubah tampilan.
Otomatis: pasang plugin Nginx Helper dari direktori plugin WordPress, aktifkan purge saat post diperbarui. Kalau ingin purge lewat HTTP, tambahkan modul libnginx-mod-http-cache-purge.

Untuk blog yang terbit sekali sehari, cara manual pun sebenarnya cukup — cukup ingat melakukannya setelah mengganti tema atau menu.

OPcache: pasangan wajib FastCGI cache

FastCGI cache menghilangkan render halaman. Tapi halaman yang lolos cache — admin, halaman login, request POST — tetap dieksekusi PHP. Di situlah OPcache bekerja: bytecode PHP disimpan di memori bersama, jadi file tidak dikompilasi ulang tiap request.

Edit /etc/php/8.5/fpm/conf.d/10-opcache.ini:


opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

Catatan penting: biarkan validate_timestamps=1. Mematikannya memang sedikit lebih cepat, tapi setiap kali kita mengedit file tema atau memperbarui plugin, perubahan itu tidak akan muncul sampai PHP-FPM di-reload — dan kita akan menghabiskan satu jam mengejar bug yang tidak ada. Setelah mengubah nilai, jalankan sudo systemctl reload php8.5-fpm.

Cek juga bahwa JIT tidak memakan memori berlebih di VPS kecil: sejak PHP 8.4 opcache.jit_buffer_size bawaannya 64M (sebelumnya 0). Di server 1–2 GB, menurunkannya ke 32M atau mematikannya dengan 0 sering lebih masuk akal daripada membiarkan memori menganggur.

Jebakan yang perlu dihindari

Jangan cache situs dengan halaman dinamis per pengunjung (keranjang WooCommerce, member area) tanpa aturan bypass yang benar-benar diuji. Cache yang salah konfigurasi bukan masalah performa, tapi masalah privasi.
Jangan lupa /wp-json/ di daftar skip. REST API yang ter-cache bisa membuat editor blok dan aplikasi mobile menampilkan data lama.
Perbarui plugin cache dengan hati-hati. Setiap perubahan tema, menu, atau widget perlu diikuti purge. Kalau lupa, kita akan mengira tema rusak padahal cache-nya yang belum dibersihkan.
Ukur sebelum dan sesudah. Catat waktu muat dari browser sebelum cache aktif, lalu bandingkan setelahnya. Tanpa angka pembanding, “terasa lebih cepat” hanya perasaan — dan perasaan tidak bisa dipakai untuk memutuskan apakah VPS perlu di-upgrade.

Kesimpulan

FastCGI cache di Nginx adalah salah satu optimasi dengan hasil paling terasa dibanding usaha yang dikeluarkan: beberapa baris konfigurasi, dan beban PHP serta database turun drastis untuk pengunjung yang tidak login. Kuncinya bukan pada direktif cache-nya, tapi pada aturan skip yang rapi.

Mulai dari yang kecil: aktifkan cache untuk halaman publik saja, uji dengan curl -I sampai HIT muncul, baru tambahkan pembersihan otomatis. Kalau ada yang aneh setelah dipasang, matikan blok cache-nya dulu (fastcgi_cache_bypass 1;), pastikan situs normal, lalu cari penyebabnya satu per satu — jangan menumpuk perubahan sekaligus.

Selamat mencoba, dan semoga VPS kita bisa bernapas lebih lega mulai hari ini. Kalau cache-nya sudah HIT terus, itu tanda kita sudah pegang kendali atas performa situs sendiri, bukan cuma berharap pada paket hosting yang lebih mahal.