Jawaban singkat untuk pertanyaan yang paling sering diajukan pembaca tentang topik ini.
Penjelasan konsep point of presence, routing anycast, cache key, header Cache-Control, purge, dan response yang tidak boleh masuk shared cache.
Matthews Wong
Software Engineer
Ringkasan Utama
CDN adalah jaringan server edge, disebut point of presence, yang menyimpan salinan response di dekat pengunjung. Routing anycast atau DNS mengarahkan tiap request ke edge terdekat, lalu cache key dan header Cache-Control menentukan apa yang dipakai ulang. Cache aset statis dan halaman publik; jangan pernah cache response personal, terautentikasi, atau yang mengubah state.
Pertanyaan ini muncul saat situs yang cepat di kotamu ternyata lambat bagi orang di benua lain: sebenarnya bagaimana CDN bekerja, dan response mana yang sebaiknya disimpan? Tutorial biasanya menjawab dengan dashboard vendor. Mekanisme di bawahnya adalah HTTP caching biasa dengan sentuhan geografis.
Post ini penjelasan konsep, bukan panduan setup. Isinya point of presence, bagaimana request menemukannya, apa itu cache key, directive Cache-Control yang penting di edge, apa yang di-cache, apa yang tidak boleh, dan cara purge. Setiap header dan perilakunya diambil dari MDN dan RFC IETF di bagian akhir, dan setiap angka adalah hitungan yang bisa kamu cek.
Content delivery network adalah kumpulan server yang tersebar secara geografis dan berada di antara pengunjung dan origin kamu. Tiap lokasi disebut point of presence, atau PoP, dan menjalankan shared cache. Pengunjung pertama yang meminta sebuah objek ke PoP menyebabkan miss, sehingga PoP mengambilnya dari origin lalu menyimpannya. Pengunjung berikutnya di dekat PoP itu mendapat hit tanpa menyentuh origin.
Ada dua konsekuensi. Pertama, setiap PoP punya cache sendiri, jadi objek yang masih dingin bisa menghabiskan satu fetch ke origin per PoP per masa berlaku. Dengan 20 PoP dan masa berlaku 300 detik, itu paling banyak 20 fetch ke origin setiap 5 menit untuk satu objek, yaitu 240 per jam, berapa pun jumlah pengunjungnya. Kedua, nilai utama CDN adalah hit ratio: pada 200 request per detik untuk sebuah gambar, hit ratio 90 persen mengirim 20 request per detik ke origin, dan 99 persen hanya 2.
Ada dua trik routing yang umum, dan banyak jaringan menggabungkannya. Pada routing berbasis DNS, authoritative DNS menjawab hostname yang sama dengan alamat IP berbeda tergantung lokasi resolver. Pada anycast, banyak PoP mengumumkan alamat IP yang sama dan protokol routing internet mengirim tiap paket ke yang dekat secara topologi, seperti dijelaskan di artikel Wikipedia tentang anycast.
Kata terdekat perlu hati-hati. Routing mengoptimalkan jarak jaringan, bukan kilometer, jadi pengunjung bisa sampai ke PoP yang bukan paling dekat di peta. Tidak ada yang perlu kamu atur, tetapi ini menjelaskan kenapa dua pengguna di satu kota bisa melihat edge berbeda, dan kenapa cache hit di satu mesin tidak berarti apa-apa untuk mesin lain.
Cache key dipakai edge untuk memutuskan apakah dua request menginginkan objek yang sama. Secara default ia dibangun dari URL, dan header response Vary menambahkan header request ke dalamnya. Apa pun yang membuat key berbeda untuk konten yang sama akan memecah cache dan menurunkan hit ratio. Blok di bawah menunjukkan penyebab yang paling sering.
# Default cache key, roughly: scheme + host + path + query string
https://shop.example.com/api/products?page=2&sort=price
https://shop.example.com/api/products?sort=price&page=2 # a DIFFERENT key, same data
# Wrong: tracking parameters in the key. Every campaign link is a miss.
https://shop.example.com/product/42?utm_source=newsletter&fbclid=abc123
# Right: ignore tracking parameters, sort the rest, so one object = one key.
https://shop.example.com/product/42
# Vary adds request headers to the key. This one doubles the cache:
Vary: Accept-Encoding # fine: a handful of values (gzip, br, identity)
Vary: Cookie # fatal: one copy per visitor, hit ratio near zeroSolusinya membuat satu objek memetakan ke satu key: normalisasi urutan query parameter, buang tracking parameter jika CDN kamu mengizinkan, dan batasi Vary ke header dengan sedikit nilai seperti Accept-Encoding. Cek apa yang dimasukkan provider kamu ke key default sebelum berasumsi, karena default berbeda antar vendor.
Cache-Control adalah tuasnya, dan RFC 9111 mendefinisikan cara cache membacanya. Dua directive paling penting untuk CDN. max-age adalah masa freshness untuk semua cache, dan s-maxage menimpanya khusus untuk shared cache seperti CDN, sehingga kamu bisa memberi tahu browser satu hal dan edge hal lain. Contoh di bawah menyimpan salinan di edge selama lima menit sementara browser selalu bertanya lagi.
// NestJS: a public catalogue endpoint the edge may keep, browsers may not.
@Get("products")
@Header(
"Cache-Control",
"public, max-age=0, s-maxage=300, stale-while-revalidate=60, stale-if-error=86400",
)
list() {
return this.products.findPublished();
}
// Fingerprinted build asset: the filename changes when the content changes.
// Cache-Control: public, max-age=31536000, immutable
// Per-user response: shared caches must not store it.
// Cache-Control: private, no-storestale-while-revalidate dan stale-if-error berasal dari RFC 5861. Dihitung dengan header di atas: objek fresh sampai Age mencapai 300 detik. Dari 300 sampai 360 detik cache boleh langsung menyajikan salinan stale sambil memperbaruinya di background, jadi tidak ada pengunjung yang menunggu. Lewat 360 detik ia harus ke origin. Jika origin sedang gagal, stale-if-error=86400 membiarkannya tetap menyajikan salinan lama hingga sehari. Header Age, yang didefinisikan di RFC 9111, memberi tahu seberapa tua salinan yang kamu terima.
RFC 9213 menambahkan header khusus CDN, yaitu CDN-Cache-Control, sehingga kebijakan edge bisa berbeda dari kebijakan browser tanpa membebani s-maxage. Dukungannya berbeda antar vendor, jadi pastikan dulu sebelum mengandalkannya. Untuk aset ber-fingerprint, MDN mendokumentasikan directive immutable, yang memberi tahu browser agar tidak revalidate selama masa berlaku.
Set max-age=0 dengan s-maxage positif pada HTML publik. Edge menyerap traffic, tetapi browser tetap revalidate, jadi purge atau deploy baru sampai ke pengguna pada request berikutnya, bukan setelah masa berlaku browser yang panjang habis.
Cache apa pun yang identik untuk semua pengunjung dan tahan jika sedikit usang. Tabel berikut mengurutkan response umum dengan uji itu, lengkap dengan header awal. Anggap masa berlakunya titik awal untuk di-tune, bukan rekomendasi yang diukur terhadap traffic kamu.
| Response | Cache di edge? | Header awal |
|---|---|---|
| JS dan CSS ber-fingerprint (app.3f9c2b1e.js) | Ya, setahun | public, max-age=31536000, immutable |
| Gambar, font, file unduhan | Ya, lama | public, max-age=86400, s-maxage=2592000 |
| HTML publik seperti blog post dan dokumentasi | Ya, singkat | public, max-age=0, s-maxage=300, stale-while-revalidate=60 |
| API GET publik yang sama untuk semua orang (katalog) | Ya, sangat singkat | public, s-maxage=30, stale-while-revalidate=30 |
| Halaman atau API per pengguna (keranjang, dashboard, invoice) | Tidak | private, no-store |
Masa berlaku yang panjang aman hanya karena nama file berubah mengikuti isinya. Karena itu optimasi edge yang paling efektif justru membosankan: taruh content hash di URL dan cache setahun.
Kegagalan yang berbahaya bukan halaman lambat, melainkan satu orang melihat data orang lain. Di ERP dan POS, halaman yang menampilkan stok, sesi kasir, atau invoice adalah tempat hal ini paling menyakitkan. Jauhkan semua ini dari shared cache apa pun.
Mengirim Vary: Cookie tidak membuat halaman personal aman untuk di-cache. Ia hanya membuat satu salinan per nilai cookie, yang menghancurkan hit ratio sambil tetap menyimpan data privat di sistem bersama. Tandai response personal sebagai private, no-store.
Ada tiga strategi, berurutan dari yang paling disukai. Beri versi pada URL sehingga tidak ada yang perlu di-purge. Pakai masa berlaku singkat dengan stale-while-revalidate untuk konten yang berubah sesuai jadwalnya sendiri. Purge eksplisit hanya untuk yang tidak bisa diberi versi.
# Strategy 1: version the URL. Nothing to purge, ever.
/assets/app.3f9c2b1e.js # new build = new name = new cache key
# Strategy 2: short TTL plus revalidation for content that changes.
Cache-Control: public, s-maxage=60, stale-while-revalidate=30
# Strategy 3: explicit purge, only for what you cannot version.
# Shape varies by vendor, so check yours. Typical options:
# purge one URL | purge by prefix | purge by tag | purge everything
# Rule of thumb: purge the URL, then let the TTL clean up the rest.Purge eksplisit paling berbahaya karena manual dan propagasinya ke tiap PoP tidak instan, dan API-nya berbeda antar vendor, jadi baca dokumentasi punyamu. Anggap purge sebagai cara mempercepat masa berlaku singkat yang sudah ada, bukan pengganti. Cache dengan masa berlaku panjang tanpa versioning hanya selangkah dari satu deploy buruk yang menyajikan halaman usang yang tidak bisa cepat diperbaiki.
Jalankan daftar ini sekali per kelompok route, bukan per URL. Sengaja dibuat pendek.
CDN adalah HTTP caching dengan banyak cache di banyak tempat, jadi aturannya sama dengan yang ada di RFC: key yang jelas, Cache-Control eksplisit, URL ber-versi, dan daftar tegas response yang tidak pernah meninggalkan origin. Tentukan dulu apa yang publik, dan konfigurasi edge hampir menulis dirinya sendiri.