Tentukan apa yang harus disajikan CDN
Mulailah dengan inventaris. Pisahkan aset yang diberi versi seperti gambar, stylesheet, skrip, font, dan unduhan dari HTML, API, halaman akun, checkout, dan administrasi. CDN sering mengisi cache on demand: permintaan pertama dapat mencapai origin, sedangkan permintaan cocok berikutnya bisa disajikan di edge. Edge yang dekat dan cache hit adalah dua manfaat berbeda.
Catat host, aplikasi, bucket penyimpanan, atau load balancer yang memasok setiap path; itu harus merespons pada cache miss.
Mulailah dengan aset yang identik untuk setiap pengunjung dan dapat aman tersedia sampai masa berlakunya berakhir.
Jangan bagikan dashboard yang dipersonalisasi, halaman terikat sesi, atau data pelanggan kecuali insinyur yang memenuhi syarat telah merancang dan menguji pemisahan.
Tetapkan kebijakan cache berdasarkan perilaku konten
Header respons HTTP menyatakan perilaku cache. Cache-Control mengatakan apakah respons boleh disimpan dan berapa lama tetap segar; time to live (TTL) adalah periode kesegaran itu. Browser adalah cache privat, sedangkan CDN biasanya bersifat bersama. Gunakan header yang eksplisit. Standar HTTP membolehkan s-maxage mengatur masa hidup cache bersama terpisah dari max-age.
Publikasikan URL baru saat konten berubah, misalnya nama file dengan content-hash, lalu beri versi yang bersifat immutable masa berlaku panjang yang terdokumentasi.
Pilih masa berlaku pendek atau perilaku validasi berdasarkan biaya konten usang; jangan gunakan aturan aset yang sama untuk harga, inventaris, atau status akun.
Gunakan private untuk respons yang ditujukan satu pengguna. Cookie saja tidak membuat respons aman untuk cache bersama.
Jadikan invalidasi pengecualian, bukan rencana rilis
Invalidasi atau purging memberitahu CDN terkelola untuk menjatuhkan objek yang disimpan sebelum kadaluarsa normal. Gunakan untuk koreksi, bukan setiap deploy. Konfirmasikan origin sudah mengembalikan pengganti sebelum mem-purge; jika tidak, pengisian ulang bisa mempertahankan respons buruk. Cache browser berada di luar kontrol purge CDN, jadi versioning URL tetap dapat diandalkan untuk berkas yang berubah.
Lebih pilih path spesifik, grup rilis, atau tag cache yang didukung penyedia ketimbang purge seluruh situs; miss luas dapat tiba-tiba membebani origin.
Purge terdistribusi mungkin tidak mencapai setiap edge bersamaan. Periksa semantik penyelesaian penyedia dan uji URL perwakilan.
Catat URL lama dan baru, aturan cache, ruang lingkup purge, hasil yang diharapkan, dan langkah pembalikan.
Jaga origin di balik lapisan pengiriman
Akses origin langsung dapat melewati cache CDN dan kontrol edge. Batasi sehingga hanya CDN, dan jalur yang dimaksudkan, yang bisa menjangkaunya. Tergantung stack Anda, gunakan kontrol akses origin cloud, aturan firewall dengan rentang egress CDN yang terdokumentasi, jaringan privat, signed origin requests, atau mutual TLS (mTLS), di mana kedua sisi saling mengautentikasi menggunakan sertifikat.
Dari lokasi uji yang berwenang, pastikan origin menolak permintaan publik sementara hostname CDN berfungsi.
Batasi health check, alat deployment, dan akses internal berdasarkan identitas dan jaringan daripada aturan publik yang luas.
Autentikasi origin berbeda menurut CDN dan origin. Gunakan panduan pengaturan penyedia saat ini dan tinjauan keamanan.
Perlakukan TLS sebagai dua koneksi
HTTPS di edge melindungi koneksi pengunjung-ke-CDN, tetapi koneksi CDN-ke-origin juga perlu perlindungan. Wajibkan enkripsi di kedua kaki, validasi sertifikat origin sesuai mode CDN, dan tetapkan kepemilikan hostname serta pembaruan. OWASP merekomendasikan TLS 1.3 sebagai default dan memperbolehkan TLS 1.2 untuk kompatibilitas; TLS 1.0 dan 1.1 sebaiknya dinonaktifkan. Minta tinjauan berkualifikasi untuk data yang diatur, aliran pembayaran, atau kompatibilitas klien yang tidak biasa.
Daftarkan pemilik sertifikat edge dan origin, jalur pembaruan, dan respons jika gagal.
Uji redirect HTTP-ke-HTTPS, canonical-host, dan deep-link untuk loop atau hilangnya path.
Enkripsi tidak membuat respons aman untuk di-cache; tetapkan aturan cache terpisah untuk halaman yang diautentikasi, personal, dan terkait pembayaran.
Uji jalur pengiriman nyata sebelum mengubah lalu lintas
Mulailah pada hostname staging atau path produksi yang sempit, lalu uji hostname CDN, bukan hanya origin. Chrome DevTools Network menunjukkan status permintaan, domain, timing, ukuran, dan header. Uji hard reload dengan cache kosong untuk mendekati kunjungan pertama, lalu kunjungan ulang untuk memeriksa reuse. Bandingkan header dan konten yang diharapkan, bukan hanya tampilan halaman yang terasa lebih cepat. Ulangi dari wilayah perwakilan ketika audiens tersebar.
Periksa Cache-Control dan header provider seperti cache-status. Konfirmasi aset publik digunakan ulang dan halaman sensitif tidak dibagikan secara tak terduga.
Latih miss, koreksi konten usang, error origin, dan rollback satu aset atau route sebelum peluncuran luas.
Simpan URL yang diuji, tangkapan header, versi aturan route, dan timing sebelum-dan-sesudah beserta catatan perubahan.
Pilih CDN berdasarkan kebutuhan operasi, lalu buktikan
Jangan memilih CDN hanya berdasarkan jumlah point-of-presence atau klaim kecepatan generik. Kinerja bervariasi dengan geografi, waktu, distribusi lalu lintas, routing, dan rasio cache hit. Bandingkan kandidat pada rute, aset, dan wilayah perwakilan. Tanyakan apakah masing‑masing mendukung kontrol cache yang Anda butuhkan, invalidasi terarah, pembatasan origin, alur kerja sertifikat, log, peran akses, harga, dukungan, dan proses perubahan.
Gunakan header cache, perilaku origin, dan halaman identik untuk kandidat; catat hasil kunjungan pertama dan kunjungan ulang secara terpisah.
Tinjau biaya permintaan, transfer, invalidasi, logging, dan dukungan, plus lonjakan cache-miss. Harga dan kontrol berbeda menurut paket.
Minta konfigurasi yang bisa diekspor, prinsip least privilege, rollback yang diuji, dan kepemilikan jelas sebelum menutup rute kritis.