Fase 8 · Cloudflare: Cache, Edge & WAF

Apa yang Cloudflare cache secara bawaan

Cache hit ratio 60% di portal berita berarti aset ter-cache dan HTML tidak. Ini materi yang menjelaskan kenapa, dan apa persisnya yang harus berubah.

Sumber asli developers.cloudflare.com Resmi Rangkuman ~9 menit baca

Intisari

Secara bawaan Cloudflare hanya meng-cache ekstensi berkas statis. HTML tidak termasuk.
Set-Cookie pada respons membuat Cloudflare tidak meng-cache — ini yang dilakukan sesi PHP di tiap request.
Cache-Control: private, no-store, atau no-cache juga membatalkannya.
s-maxage untuk CDN, max-age untuk browser. Keduanya berbeda dan harus disetel terpisah.
Periksa header cf-cache-status: HIT, MISS, DYNAMIC, BYPASS — masing-masing berarti hal berbeda.

Diagnosis portalmu

Total request     : 1.250.000 / jam
Dilayani Cloudflare:   750.000 / jam   (60%)
Sampai ke origin  :   500.000 / jam   (40%)

Enam puluh persen terdengar tidak buruk sampai kamu memecahnya per jenis konten. Portal berita tipikal memuat 10–30 aset per halaman: CSS, JS, gambar, font. Kalau seluruh aset ter-cache dan seluruh HTML tidak, angka 60% itu persis yang kamu harapkan.

# Buktikan sendiri
curl -sI https://portal.contoh.id/berita/artikel-apa-saja | grep -i 'cf-cache-status\|cache-control\|set-cookie'
curl -sI https://portal.contoh.id/assets/style.css       | grep -i 'cf-cache-status'

`cf-cache-status`	Artinya	Untukmu
`HIT`	Dari edge, tidak menyentuh origin	Yang kamu mau
`MISS`	Tidak ada di edge, diambil dari origin lalu disimpan	Normal untuk yang pertama
`EXPIRED`	Ada tapi kedaluwarsa, disegarkan	Normal
`REVALIDATED`	Origin menjawab 304	Hemat bandwidth, tapi origin tetap bekerja
`STALE`	Disajikan basi sambil disegarkan	Bagus — pembaca tidak menunggu
`BYPASS`	Sesuatu melarang cache	Cari penyebabnya
`DYNAMIC`	Cloudflare menganggapnya tidak layak di-cache	Ini yang terjadi pada HTML-mu

DYNAMIC pada halaman artikel adalah temuan utamamu. Ia berarti Cloudflare bahkan tidak mencoba — karena secara bawaan HTML tidak termasuk yang di-cache. Bukan karena origin-mu melarang; karena tidak ada yang menyuruhnya.

Yang di-cache secara bawaan

Cloudflare memakai daftar ekstensi berkas: .css, .js, .jpg, .png, .webp, .woff2, .pdf, dan sejenisnya.

URL	Bawaan
`/assets/style.abc123.css`	Di-cache
`/gambar/sampul.jpg`	Di-cache
`/berita/rupiah-menguat`	Tidak
`/`	Tidak
`/api/artikel.json`	Tidak

Empat hal yang membatalkan cache

Penyebab	Dari mana datangnya di portalmu
`Set-Cookie` pada respons	Sesi PHP CI3 di tiap request
`Cache-Control: private`	Bawaan banyak framework saat sesi aktif
`Cache-Control: no-store` / `no-cache`	Sama
Metode selain `GET`/`HEAD`	Form dan API — memang seharusnya

// Inilah yang dilakukan CI3 di setiap request, termasuk untuk pembaca anonim:
// Set-Cookie: ci_session=abc123; path=/
// Cache-Control: no-store, no-cache, must-revalidate
//
// Cloudflare membacanya sebagai: "jangan simpan ini".
// Ia patuh. Setiap kali.

Ini akar masalahnya, dan perbaikannya struktural, bukan konfigurasi. Selama halaman artikel mengirim Set-Cookie, tidak ada pengaturan Cloudflare yang bisa membuatnya aman di-cache — memaksanya justru berarti cookie sesi satu pembaca ikut tersimpan dan tersaji ke pembaca lain. Arsitektur Astro dengan server island (Fase 1 dan 5) yang membuat halamannya bersih dari cookie, dan itulah yang membuka jalan bagi seluruh materi di fase ini.

Dua arahan yang berbeda

Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=86400
                       ─────────  ────────────  ──────────────────────────
                       browser    Cloudflare    Cloudflare

Arahan	Untuk	Nilai untuk artikel	Kenapa
`max-age`	Browser pembaca	`0`	Koreksi artikel harus langsung terlihat saat pembaca memuat ulang
`s-maxage`	Cloudflare	`300`	Ini yang menyerap trafiknya
`stale-while-revalidate`	Cloudflare	`86400`	Pembaca tidak pernah menunggu origin
`stale-if-error`	Cloudflare	`86400`	Origin mati → sajikan basi, bukan 502

max-age=0 terlihat seperti mematikan cache, tapi tidak: browser akan bertanya, dan yang menjawabnya adalah Cloudflare dari edge — bukan origin-mu. Pembaca tetap mendapat respons dalam puluhan milidetik, dan kamu tetap bisa memperbaiki artikel tanpa menunggu cache browser siapa pun kedaluwarsa.

Target yang realistis

	Sekarang	Setelah Fase 8
Cache hit ratio	60%	92–95%
Request ke origin	500.000 / jam	~75.000 / jam
Rata-rata req/detik ke origin	139	~21
Puncak req/detik ke origin	~400	~60
Egress AWS	~10,8 TB/bulan	~1,6 TB/bulan

Angka terakhir itu yang membiayai seluruh proyek migrasi ini. Dengan asumsi rata-rata respons 30 KB dan tarif egress standar, selisihnya sekitar 800–850 dolar per bulan — sebelum menghitung penghematan dari instance ECS yang lebih sedikit. Ukur ukuran respons rata-ratamu yang sebenarnya untuk mendapat angka yang tepat.

Latihan: jalankan curl -sI pada lima jenis URL di portalmu — beranda, artikel, kategori, aset CSS, dan gambar — lalu catat cf-cache-status, cache-control, dan ada tidaknya set-cookie untuk masing-masing. Tabel itu adalah dasar sebelum-sesudah untuk seluruh fase ini. Lalu buka Analytics → Caching di dashboard Cloudflare dan catat rasio saat ini per jenis konten.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.