Pelajari durasi cache CDN default dan cara mengonfigurasi waktu kedaluwarsa cache - CDN

Dengan mengonfigurasi aturan waktu kedaluwarsa cache, Anda dapat mengontrol secara tepat berapa lama resource di-cache pada POP (points of presence) untuk menyeimbangkan pembaruan konten, kinerja akses, dan biaya pengambilan dari origin. Dokumen ini menjelaskan cara kerja aturan cache, cara mengonfigurasi dan memverifikasinya, serta menyediakan langkah troubleshooting dan praktik terbaik.

Cara kerja

Saat permintaan mencapai POP, sistem menggunakan alur keputusan berikut untuk menentukan apakah akan menyajikan salinan yang di-cache atau mengambil konten terbaru dari origin server.

Jangan cache resource: Saat origin server merespons dengan pragma:no-cache, cache-control:no-cache (atau no-store, atau max-age=0), POP mengikuti kebijakan origin dan tidak melakukan caching terhadap resource tersebut.

Mengikuti aturan cache konsol: Jika Anda telah mengonfigurasi aturan untuk direktori atau ekstensi file tertentu di konsol, dan origin server tidak mengirim header "jangan cache" yang disebutkan di atas, aturan cache konsol memiliki prioritas lebih tinggi.

Logika prioritas saat beberapa aturan cache konsol sesuai:

Skenario	Logika	Contoh
Bobot berbeda	Aturan dengan nilai Weight lebih tinggi (1–99) memiliki prioritas lebih tinggi.	Jika Aturan A (untuk direktori `/image/`, Weight 50) dan Aturan B (untuk ekstensi `.jpg`, Weight 90) sama-sama sesuai dengan `image/a.jpg`, maka Aturan B yang diterapkan.
Bobot sama	Aturan yang dibuat lebih dulu memiliki prioritas lebih tinggi.	Jika Anda mengonfigurasi aturan direktori (`/static/`) dan aturan ekstensi file (`.js`) dengan Weight yang sama yaitu 60, dan aturan direktori dibuat sebelum aturan ekstensi, maka `/static/app.js` akan sesuai dengan aturan direktori.

Begitu permintaan sesuai dengan suatu aturan cache, aturan lain tidak lagi diperiksa.
Secara default, jika origin server merespons dengan Pragma: no-cache atau Cache-Control: no-cache/no-store/max-age=0, POP tidak melakukan caching terhadap resource tersebut. Untuk memaksa caching, pilih Ignore Origin No-cache Header saat mengonfigurasi aturan cache di konsol.

CDN mengikuti kebijakan cache origin server: Jika permintaan tidak sesuai dengan aturan konsol apa pun, atau jika aturan yang sesuai memiliki opsi Honor Origin TTL diaktifkan, CDN menghormati header respons HTTP dari origin server. Prioritas header tersebut, dari tertinggi ke terendah: cache-control > expires > last-modified > ETag.

Header respons	Cara penanganan	Contoh
Cache-Control	Direktif `s-maxage` diprioritaskan untuk durasi cache, diikuti oleh `max-age`.	`s-maxage=86400, max-age=3600`
Expires	Menentukan tanggal dan waktu kedaluwarsa. Ini hanya digunakan jika header `Cache-Control` tidak ada.	`Expires: Wed, 21 Oct 2025 07:28:00 GMT`
Last-Modified	`Last-Modified` adalah timestamp yang menunjukkan kapan resource terakhir dimodifikasi. Durasi cache dihitung sebagai berikut: (Waktu Saat Ini - `Last-Modified`) * 0,1, dengan durasi hasil dibatasi dalam rentang 10 hingga 3.600 detik.	`Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT`
ETag	`ETag` adalah pengenal unik yang dihasilkan server untuk versi spesifik suatu resource, biasanya berupa nilai hash atau nomor versi. Secara default, resource dengan `ETag` di-cache selama 10 detik.	`ETag: "abc123"`

Kebijakan no-cache: Jika permintaan tidak sesuai dengan aturan cache konsol apa pun dan origin server tidak mengembalikan header respons terkait cache (seperti Cache-Control), POP tidak melakukan caching terhadap resource tersebut.

Catatan

Kebijakan cache hanya diterapkan pada respons dengan kode status 200, 203, 206, 300, 301, 308, atau 410 dari origin server. Untuk melakukan caching terhadap respons dengan kode status lain (misalnya 404), konfigurasikan pengaturan ini pada halaman Status Code TTL di halaman Cache Settings.

Prosedur

Melalui konsol (disarankan)

Di konsol CDN, buka halaman Domain Names dan klik Manage pada baris domain target Anda.
Pada halaman Cache > Cache Expiration, klik Add untuk mengonfigurasi aturan cache baru.

Tambahkan waktu kedaluwarsa cache	Parameter	Deskripsi
	Type	Tentukan cakupan aturan berdasarkan Directory atau File Extension. • Directory: Tetapkan aturan cache seragam untuk semua resource di bawah suatu path. • File Extension: Tetapkan aturan cache seragam untuk file dengan tipe tertentu.
	Object	Masukkan konten berdasarkan tipe yang dipilih: • Directory: Harus diawali dengan `/` (misalnya, `/static/`). Satu `/` saja cocok dengan semua path. Hanya satu direktori yang dapat ditambahkan sekaligus. • File Extension: Masukkan satu atau beberapa ekstensi yang dipisahkan koma (misalnya, `jpg,css`). Entri bersifat case-sensitive dan tidak mendukung wildcard (`*`).
	Expire In	Durasi resource di-cache pada POP CDN. Maksimum 3 tahun. • Untuk resource statis yang jarang diperbarui (misalnya, citra, paket instalasi), disarankan durasi ≥1 bulan. • Untuk resource statis yang sering diperbarui (misalnya, JS/CSS), atur durasi sesuai kebutuhan. • Untuk konten dinamis (misalnya, PHP/JSP), disarankan durasi 0 detik (tidak di-cache).
	Honor Origin TTL	Jika diaktifkan, kebijakan cache origin server memiliki prioritas dan menggantikan aturan ini.
	Ignore Origin No-Cache Header	Jika diaktifkan, CDN mengabaikan header `no-cache` berikut dari origin server: `Cache-Control: no-store`, `no-cache`, `max-age=0`, dan `Pragma: no-cache`. Resource di-cache sesuai aturan konsol.
	Follow POP Cache Policy	Jika diaktifkan, CDN mengirim kebijakan cache efektifnya (misalnya, `max-age=3600`) ke client melalui header respons `Cache-Control`.
	Force Revalidation	Pengaturan ini hanya berlaku ketika Waktu Kedaluwarsa diatur ke 0 detik. Nonaktif (default): Saat waktu kedaluwarsa cache diatur ke 0, file tidak di-cache pada POP. Setiap permintaan diambil langsung dari origin. Aktif: Saat waktu kedaluwarsa cache diatur ke 0, file dapat di-cache pada POP, tetapi POP melakukan revalidasi konten yang di-cache dengan origin untuk setiap permintaan.
	Weight	Prioritas aturan. Nilainya berkisar antara 1 hingga 99. Nilai lebih tinggi berarti prioritas lebih tinggi. • Jika dua aturan memiliki Weight yang sama, aturan yang dibuat lebih dulu memiliki prioritas lebih tinggi. • Begitu permintaan sesuai dengan suatu aturan, aturan berikutnya tidak lagi diperiksa.
	Rule Condition	Anda dapat mempersempit cakupan aturan berdasarkan parameter permintaan (misalnya, Header, parameter URL). • Secara default, ini Not used. Untuk mengonfigurasi kondisi, kelolanya di Rule Engine.

Menggunakan API

Panggil operasi BatchSetCdnDomainConfig untuk mengonfigurasi domain secara batch.

Terapkan perubahan aturan secara langsung

Aturan baru atau yang dimodifikasi hanya berlaku untuk resource yang baru di-cache. Resource yang sudah di-cache sebelum perubahan akan tetap menggunakan kebijakan cache lama hingga masa berlakunya habis.

Untuk menerapkan aturan baru ke seluruh jaringan secara langsung, Anda harus membersihkan cache yang ada secara manual. Jika Anda mengubah aturan, refresh konten yang di-cache dengan menggunakan fitur Purge resource. Jika Anda menambahkan aturan baru, isi cache terlebih dahulu dengan menggunakan fitur Prefetch resource.

Verifikasi konfigurasi

Setelah konfigurasi, Anda dapat menggunakan perintah curl atau alat developer browser untuk memeriksa header respons HTTP suatu resource guna memverifikasi bahwa caching berjalan sesuai harapan.

1. Jalankan perintah verifikasi

Jalankan perintah berikut di terminal Anda untuk menguji konfigurasi.

curl -I "https://your.domain.com/path/to/file.jpg"

2. Interpretasi header respons utama

Header respons	Nilai umum dan interpretasi
`X-Cache`	Menunjukkan apakah permintaan merupakan cache hit. - `HIT`: Permintaan mengenai cache. - `MISS`: Permintaan merupakan cache miss, dan resource diambil dari origin server.
`Cache-Control`	Jika Client follows CDN cache policy diaktifkan, header ini menampilkan direktif cache yang dikirim ke browser, seperti `max-age=3600`.
`X-Swift-CacheTime`	Total durasi cache yang dikonfigurasi untuk resource pada POP CDN, dalam detik.

Praktik terbaik

Gunakan nama file berbasis versi (disarankan): Saat memperbarui resource statis seperti style.css, gunakan nama file baru dengan versi atau nilai hash, seperti style-v2.css atau style-a1b2c3d.css, dan perbarui referensinya di HTML Anda. Metode ini tidak memerlukan refresh cache manual dan memastikan pengguna langsung mendapatkan konten terbaru. Ini adalah cara yang direkomendasikan untuk mengelola pembaruan cache.
Pisahkan aset dinamis dan statis: Gunakan domain atau path direktori berbeda untuk resource dinamis dan statis. Konfigurasikan aturan cache terpisah dengan bobot tinggi untuk masing-masing tipe resource guna menghindari konflik kebijakan. Misalnya, atur durasi cache panjang untuk semua resource di bawah direktori /static/ dan atur no-cache untuk resource di bawah direktori /api/.
Manfaatkan cache browser: Aktifkan Follow POP Cache Policy untuk mengurangi permintaan berulang ke POP, yang meningkatkan kecepatan pemuatan dan menghemat traffic.
Hindari mengatur durasi cache terlalu singkat: Durasi cache yang terlalu singkat menyebabkan permintaan ke origin menjadi sering, sehingga menghilangkan manfaat akselerasi dan meningkatkan traffic serta biaya server origin Anda.
Hindari mengatur durasi cache terlalu lama: Durasi cache yang terlalu lama dapat mencegah klien menerima pembaruan data secara tepat waktu. Untuk konten yang perlu sering diperbarui, gunakan fitur refresh cache atau nama file berbasis versi.

Mekanisme kontrol cache HTTP

Protokol HTTP mendefinisikan tiga jenis header untuk mengimplementasikan kontrol cache.

Validasi waktu kedaluwarsa

Saat server mengirim resource, server dapat menyertakan waktu kedaluwarsa dalam respons. Sebelum waktu tersebut, resource (salinan yang di-cache) dianggap fresh. Setelah waktu tersebut, resource dianggap stale.

Dalam HTTP, header berikut umum digunakan untuk mengontrol kedaluwarsa cache:

Nama header	Versi protokol	Fungsi	Nilai contoh	Tipe
Pragma	HTTP/1.0	`Pragma` digunakan untuk menunjukkan apakah konten harus di-cache. Nilainya biasanya `no-cache`. Sering digunakan untuk kompatibilitas dengan server yang hanya mendukung HTTP/1.0.	`Pragma:no-cache`	Permintaan/Respons
Expires	HTTP/1.0	Header respons `Expires` berisi tanggal/waktu setelah mana konten yang di-cache dianggap stale. Tanggal yang tidak valid, seperti `0`, menunjukkan bahwa resource sudah kedaluwarsa.	`Expires: Wed, 21 Oct 2022 07:28:00 GMT`	Respons
Cache-Control	HTTP/1.1	Header respons `Cache-Control` dapat diatur dengan berbagai direktif untuk kontrol cache yang fleksibel. Ini adalah header utama yang digunakan klien modern (seperti browser) untuk mengontrol caching.	Tiga contoh berikut berarti file tidak boleh di-cache: - `Cache-Control:no-cache` - `Cache-Control:no-store` - `Cache-Control:max-age=0` Contoh yang menunjukkan validitas cache selama 1 jam: `Cache-Control:max-age=3600`	Permintaan/Respons

Validasi tag resource

Saat klien meminta resource, server dapat menyertakan tag resource (seperti `ETag`) dalam respons. Klien kemudian menyimpan tag ini. Untuk permintaan berikutnya terhadap resource yang sama, klien mengirim kembali tag tersebut ke server. Jika tag tersebut sesuai dengan versi terkini di server, server merespons dengan status `304 Not Modified`, memberi tahu klien untuk menggunakan salinan yang di-cache-nya. Jika tag tidak sesuai, server mengirim resource lengkap yang telah diperbarui.

Dalam HTTP, header berikut umum digunakan untuk mengontrol versi cache:

Nama header	Versi protokol	Fungsi	Nilai contoh	Tipe
Last-Modified	HTTP/1.0	`Last-Modified` menunjukkan waktu terakhir resource dimodifikasi.	`Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT`	Respons
ETag	HTTP/1.1	`ETag` menyediakan pengenal unik untuk versi spesifik suatu resource. Membandingkan nilai `ETag` dapat menentukan apakah resource telah berubah. Jika tidak, origin server tidak perlu mengirim respons lengkap.	`ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"`	Respons

Negosiasi konten

Perangkat lunak caching menggunakan kunci untuk mengindeks objek yang di-cache. Dalam HTTP/1.0, kunci ini biasanya berupa URL resource. Namun, resource berbeda dapat berada pada URL yang sama. Untuk membedakannya, informasi tambahan diperlukan dari klien, seperti header Accept-Language dan Accept-Charset. Untuk mendukung negosiasi konten ini, HTTP/1.1 memperkenalkan header Vary dalam respons, yang mencantumkan header permintaan yang digunakan untuk negosiasi konten.

Header HTTP `Vary` adalah mekanisme untuk hal ini. Header tersebut memberi tahu cache header permintaan mana yang harus diperiksa saat menentukan apakah respons yang di-cache dapat digunakan.

Nama header	Versi protokol	Deskripsi	Nilai contoh	Tipe
Vary	HTTP/1.1	Contoh umum: - Server menentukan: `<br> Vary: Accept-Encoding<br>` Ini memberi tahu penerima (misalnya, POP) untuk menyimpan dua versi resource (terkompresi dan tidak terkompresi). Saat klien meminta resource, browser lama dapat menerima versi tidak terkompresi untuk kompatibilitas, sedangkan browser modern menerima versi terkompresi untuk mengurangi transfer data dan traffic. - Server menentukan: `<br> Vary: User-Agent<br>` Ini digunakan untuk mengidentifikasi tipe browser dan memberi tahu penerima (misalnya, POP) untuk menyimpan versi berbeda dari resource berdasarkan tipe browser.	`Vary: Accept-Encoding` `Vary: Accept-Encoding,User-Agent`	Respons

CDN：Konfigurasikan waktu kedaluwarsa cache CDN