Kenapa Caching Bisa Balik Ngelempar

Gue Tambahin CDN Cache, Malah Jadi Lebih Lambat. Inilah Matematikanya yang Harusnya Gue Hitung Dulu.

Minggu lalu, gue coba optimasi yang kelihatannya gampang banget. Gue nambahin layer cache CDN (Content Delivery Network) di depan site statis gue, mikir bakal dapet cerita biasa: load time lebih cepat, user senang, skor SEO naik. Eh malah kebalikannya. Site gue jadi *measurably* lebih lambat. Bukan sediki — crawler independen yang sebelumnya nge-flag 38 detik load time, tiba-tiba ngeraporin 52 detik. Sakit.

Ini bukan pertama kalinya optimasi infrastruktur malah balik ngelempar. Tapi ini *humbling reminder* banget: layer caching punya *performance tax*-nya sendiri. Sebelum kamu asal copot CDN ke stack kamu, ini matematikanya yang gue pengen gue jalanin dulu.

Kenapa Caching Bisa Balik Ngelempar

Sepintas, CDN keliatannya *pure win-win*. Kamu pindahin static assets ke dekat user, kurangi beban server, perbaiki latency global. Tapi tiap cache nambahin overhead:

1. **Latensi dari keputusan cache**: Request ini cached nggak? Harus revalidasi? Header apa yang berlaku?
2. **Network hops**: Edge nodes pun nggak selamanya deket sama user
3. **Cache misses**: Pas cache expired atau di-purge, user bayar full origin latency *plus* delay proses CDN
4. **Kompresi dan transformasi**: Banyak CDN kompres atau modifikasi konten, nambah waktu proses

Di kasus gue, pelakunya bukan CDN-nya sendiri — tapi **konfigurasi cache-nya**. Defaultnya, banyak setup CDN cache agresif file kecil tapi biarin file besar uncached, bikin pengalaman user jadi inconsistennya.

Angka yang Sebenernya Penting

Sebelum pasang solusi caching apa pun, jalanin kalkulasi ini:

Cache Hit Ratio
```
Hit Ratio = Hits / (Hits + Misses)
```

Kalo kamu cuma hit cache 60% waktu, berarti 40% request kamu bayar overhead CDN untuk *zero benefit*. Targetnya >85%.

Effective Latency
```
Effective Latency = (Hit Rate × Edge Latency) + (Miss Rate × (Edge + Origin Latency))
```

Contoh:
Edge latency: 50ms
Origin latency: 300ms
Hit rate: 90%
Effective latency: (0.9 × 50) + (0.1 × 350) = 80ms

Bandingin sama direct origin: 300ms. CDN menang.

Tapi kalo hit rate turun jadi 60%:
Effective latency: (0.6 × 50) + (0.4 × 350) = 170ms
Masih lebih cepet, tapi *barely worth the complexity*.

Optimasi Time-to-Live (TTL)
TTL pendek (< 30 detik) berarti lebih banyak fetch ke origin. TTL panjang (> 24 jam) berarti konten *stale*. Cari balance berdasarkan frekuensi update.

Skenario Real World di Mana Gue Akan Skip CDN

1. Audiens Utama Lokal
Kalo 90% traffic kamu dari satu region geografis, CDN cuma nambah complexity yang gak perlu. Origin server yang dikonfigurasi dengan baik mungkin performanya lebih baik.

Contoh: Website restoran lokal yang melayani customer sekitarnya gak dapet benefit signifikan dari global edge caching.

2. Konten Sangat Dinamis
Buat site yang kontennya update setiap beberapa menit (kayak news dashboard), TTL pendek memaksa revalidasi konstan. Cache jadi liability, bukan asset.

Contoh: Dashboard analytics gue pull live data setiap 30 detik. Caching di sini bakal إما nampilin info outdated atau butuh logic invalidasi yang ribet.

3. Ukuran File Kecil
CDN optimize proximity jaringan, tapi kalo file kamu kecil (di bawah 10KB), overhead routing lewat CDN bisa melebihi hemat waktu transfer.

Contoh: JSON API response di bawah 5KB sering load lebih cepat langsung dari origin daripada lewat proses edge CDN.

Tools Buat Diagnosa Performa

Sebelum asumsikan CDN = improvement, ukur baseline performa pake:

- **WebPageTest.org**: Waterfall chart detail nunjukin waktu dihabisin di mana
- **Lighthouse CI**: Audit performa otomatis di pipeline deployment kamu
- **Real User Monitoring (RUM)**: Tools kayak [PostHog](https://posthog.com/) atau [Plausible](https://plausible.io/) nampilin pengalaman user asli

Jalankan test dari multiple lokasi geografis buat ngerti pengalaman asli audiens kamu.

Nge-fix Kesalahan Gue Sendiri

Setelah diagnosa masalah, gue ubah pendekatan:

1. Naikin cache TTL dari 30 detik jadi 6 jam buat static assets
2. Implement cache tags yang proper buat invalidasi dinamis
3. Tambahin pre-warming logic buat endpoint populer
4. Monitor hit ratios terus menerus pake [Cloudflare Analytics](https://www.cloudflare.com/analytics/)

Hasilnya? Load time turun dari 52 detik jadi 1.2 detik global.

Kesimpulannya

CDN bukan *magic bullet*. Tools canggih yang butuh *tuning* hati-hati. Selalu bikin baseline metrics sebelum optimasi, dan jangan pernah asumsikan default settings bakal work buat use case spesifik kamu.

Test yang thorough, ukur impact, dan ingat: kadang **ngilangin complexity justru lebih baik daripada nambahinnya**.

FAQ

Harus selalu pake CDN?
Gak harus. Evaluasi berdasarkan geografis audiens, tipe konten, dan frekuensi update. Audiens lokal dengan file kecil mungkin gak dapet benefit.

Cache hit ratio berapa yang acceptable?
Target 85% atau lebih. Di bawah 70%, pertimbangin lagi apakah overhead CDN worth it.

Berapa lama seharusnya cache static assets?
Buat asset yang divisikan (dengan hash filename), cache selamanya. Buat yang lain, 1-24 jam tergantung frekuensi update.

Bisa CDN ngehurt SEO?
Bisa, kalo nge-increase load time atau serve konten yang inconsistent. Google masukkin page speed ke ranking, jadi monitor Core Web Vitals deket-deket.