Kepala Cache HTTP Cache-Control, ETag, dan max-age Tanpa Menebak

Setiap respons HTTP yang Anda kirimkan akan disimpan di cache atau tidak — dan jika Anda tidak sengaja terhadap hal ini, browser akan mengambil keputusan untuk Anda. Hasilnya biasanya adalah kombinasi penundaan yang agresif untuk hal-hal yang sering berubah dan tidak ada penundaan untuk hal-hal yang jarang berubah. Kedua hal ini merugikan pengguna Anda.

Panduan ini memberikan model mental untuk menetapkan header cache HTTP secara benar pertama kali: apa yang dikontrol oleh setiap direktif, bagaimana ETag memicu revalidasi, dan bagaimana memilih TTL yang bertahan saat deployasi tanpa menyajikan konten yang sudah usang.

Cara cache browser sebenarnya bekerja

Ketika browser meminta sumber daya, ia terlebih dahulu memeriksa cache lokalnya. Jika salinan terbaru ada di cache, ia langsung menyajikannya — tanpa permintaan jaringan sama sekali. Jika salinan di cache mungkin sudah usang, ia mengirimkan permintaan kondisional ke sumber. Sumber tersebut kemudian mengonfirmasi bahwa sumber daya tidak berubah (304 Not Modified) atau mengirimkan respons yang diperbarui secara penuh (200 OK).

CDN berada di tengah siklus ini. Mereka menyimpan respons yang lebih dekat dengan pengguna secara geografis, dan mereka mengikuti header cache HTTP yang sama — dengan beberapa ekstensi khusus untuk CDN seperti s-maxage.

Tiga pertanyaan menentukan perilaku caching:

• Apakah respons ini dapat disimpan di cache? Dikontrol oleh Cache-Control: no-store atau private
• Berapa lama respons ini masih segar? Dikontrol oleh max-age atau s-maxage
• Bagaimana validasi keusangan dilakukan? Dikontrol oleh ETag atau Last-Modified

Direktif header Cache-Control

Itu Cache-Control header adalah cara utama untuk menyatakan kebijakan caching. Beberapa direktif dipisahkan dengan koma. Berikut ini apa yang dilakukan oleh setiap satu dari mereka:

max-age

max-age=N mengatakan kepada cache (browser dan CDN) berapa banyak detik respons tetap segar. Respons dengan max-age=86400 dianggap segar selama tepat 24 jam dari saat diterima. Setelah itu, cache harus melakukan revalidasi sebelum menyajikannya lagi.

Untuk aset statis dengan nama file yang di-version (seperti main.abc123.js), satu tahun biasanya digunakan: max-age=31536000. Untuk dokumen HTML, jendela yang jauh lebih pendek — atau tidak ada caching sama sekali — lebih aman, karena HTML merujuk pada aset yang di-version.

s-maxage

s-maxage menggantikan max-age untuk cache bersama (CDN, server proxy) saja. Browser mengabaikannya. Ini memungkinkan Anda menyajikan respons yang sudah lama disimpan kepada pengguna, sementara menjaga edge CDN tetap lebih segar. Pola umumnya adalah Cache-Control: public, max-age=3600, s-maxage=86400 — browser menyimpannya selama 1 jam, CDN menyimpannya selama 24 jam.

no-cache

no-cache tidak berarti "jangan disimpan di cache." Ini berarti cache harus melakukan revalidasi dengan sumber sebelum menyajikan respons yang disimpan, bahkan jika masih segar. Respons disimpan, tetapi setiap penggunaan membutuhkan satu perjalanan untuk memastikan kevalidannya. Ini sesuai untuk konten yang sering berubah tetapi mendapat manfaat dari penghematan bandwidth dari respons 304.

no-store

no-store adalah satu-satunya direktif yang benar-benar mencegah caching. Tidak ada cache browser, tidak ada cache CDN, tidak ada penulisan ke disk. Gunakan ini untuk respons yang mengandung data sensitif pengguna — seperti statement bank, catatan medis, token. Jangan gunakan ini sebagai default karena Anda belum mempertimbangkan caching.

public dan private

public secara eksplisit memungkinkan cache bersama (CDN) menyimpan respons, bahkan ketika permintaan memiliki Authorization header. private menghentikan caching hanya untuk browser pengguna — CDN tidak boleh menyimpannya. Untuk respons yang autentikasi dan spesifik untuk pengguna, private mencegah respons satu pengguna disajikan kepada pengguna lain.

must-revalidate

must-revalidate mencegah cache menyajikan respons yang usang ketika tidak dapat mencapai sumber. Tanpa ini, cache mungkin menyajikan respons yang sudah kadaluwarsa jika jaringan tidak tersedia. Dengan ini, permintaan gagal dengan kode 504 jika sumber tidak dapat diakses. Gunakan ini untuk konten di mana menyajikan data usang lebih buruk daripada kesalahan.

ETags: revalidasi presisi

ETag adalah identifikasi yang dihasilkan oleh server untuk versi tertentu dari sumber daya — pikirkan sebagai "fingerprint" untuk isi respons. Server mengirimkannya dalam respons:

ETag: "abc123def456"

Ketika salinan di cache kedaluwarsa, browser mengirimkan permintaan GET kondisional dengan ETag yang tersimpan:

If-None-Match: "abc123def456"

Jika sumber daya tidak berubah, server merespons dengan 304 Not Modified dan tubuh kosong — menghemat bandwidth sambil tetap memastikan kebaruan. Jika telah berubah, server merespons dengan 200 OK dan ETag baru.

Strong vs weak ETags

A strong ETag ("abc123") berarti respons identik secara byte-ke-byte. Sebuah weak ETag (W/"abc123") berarti respons secara semantik setara tetapi mungkin berbeda dalam hal kecil seperti spasi atau urutan header. ETag lemah dapat dihasilkan lebih efisien tetapi tidak dapat digunakan dalam permintaan range. Kecuali Anda memiliki alasan khusus untuk menggunakan ETag lemah, gunakan yang kuat.

Last-Modified: alternatif yang lebih tua

Sebelum ETag, server menggunakan Last-Modified timestamp untuk revalidasi. Server mengirimkan:

Last-Modified: Thu, 01 May 2026 12:00:00 GMT

Browser melakukan revalidasi dengan:

If-Modified-Since: Thu, 01 May 2026 12:00:00 GMT

Server mengembalikan 304 jika sumber daya tidak berubah sejak timestamp tersebut.

Kekurangannya: timestamp memiliki ketelitian satu detik. File yang diubah dua kali dalam satu detik akan tampak tidak berubah. ETag menangani ini dengan benar dan lebih disukai. Sebagian besar kerangka kerja modern mengirimkan keduanya — browser menggunakan yang tersedia, dengan ETag mendapat prioritas.

Menghancurkan cache tanpa mengganggu deployasi

Nilai max-age yang panjang pada aset statis hanya aman jika URL berubah saat konten berubah. Ada dua strategi:

Pencitraan URL (disarankan)

Sertakan hash dari isi file dalam nama file: main.a1b2c3d4.js. Ketika file berubah, hash berubah, URL berubah, dan browser mengambil file baru — menghindari cache sepenuhnya. URL lama tetap ada di cache tetapi tidak lagi diminta setelah HTML merujuk ke URL baru.

Webpack, Vite, dan kebanyakan bundler modern melakukan ini secara otomatis. Pola ini memungkinkan Anda secara aman menetapkan Cache-Control: public, max-age=31536000, immutable — direktif immutable mengatakan browser tidak perlu melakukan revalidasi bahkan jika entri cache secara teknis sudah usang.

Query string (kurang dapat diandalkan)

Menambahkan versi ke URL sebagai query string (main.js?v=1.2.3) secara teknis menciptakan URL yang berbeda, tetapi beberapa CDN dan proxy mengabaikan query string saat membuat kunci cache. Pencitraan URL di jalur lebih dapat diandalkan dan didukung secara universal.

Kesalahan umum yang merugikan caching

Menyimpan respons API yang seharusnya tidak disimpan di cache

API JSON yang mengembalikan data yang spesifik untuk pengguna atau sensitif terhadap waktu harus menggunakan Cache-Control: no-store atau setidaknya private, no-cache. Kesalahan umum adalah membiarkan CDN menyimpan respons seperti /api/user/profile dan menyajikan data satu pengguna kepada pengguna lain. Jika API Anda tidak menetapkan header Cache-Control , beberapa CDN akan menyimpannya sendiri menggunakan heuristik.

Lupa Vary: Accept-Encoding

Jika server menyajikan versi terkompresi dan tidak terkompresi dari sumber daya tergantung pada header Accept-Encoding pengguna, cache harus menyimpan salinan terpisah untuk setiap varian. Tanpa Vary: Accept-Encoding, CDN mungkin menyimpan versi gzip dan menyajikannya kepada pengguna yang tidak mendukung gzip — atau sebaliknya. Selalu atur saat kompresi bersifat kondisional.

Menggunakan no-cache ketika maksud Anda adalah no-store

Pengembang sering menulis Cache-Control: no-cache ketika mereka ingin mencegah caching sepenuhnya, tetapi no-cache tetap menyimpan respons — hanya membutuhkan revalidasi sebelum setiap penggunaan. Gunakan no-store ketika Anda benar-benar tidak ingin respons disimpan di mana pun.

Menetapkan max-age pada HTML tanpa strategi cache-busting

Dokumen HTML merujuk pada aset yang di-version. Jika Anda menyimpan HTML dengan nilai max-ageyang panjang, pengguna tidak akan memperoleh nama file aset baru setelah deploy — mereka akan terus menjalankan HTML lama yang merujuk pada hash lama. Tetapkan TTL yang pendek (atau no-cache) pada HTML, dan reservasi TTL panjang untuk aset yang tidak berubah yang dirujuk oleh HTML.

Hitung jendela kedaluwarsa sebelum Anda meluncurkan

Pemilihan nilai max-age lebih mudah ketika Anda dapat melihat apa artinya dalam waktu dinding. Nilai Kalkulator TTL Cache HTTP / max-age pada iotools.cloud memungkinkan Anda memasukkan TTL dalam detik dan melihat waktu kedaluwarsa yang tepat. Berguna untuk memeriksa nilai seperti 86400 (24 jam), 2592000 (30 hari), atau 31536000 (1 tahun) sebelum mengonfirmasikannya ke konfigurasi server atau aturan CDN.

Daftar periksa kebijakan cache praktis

• Dokumen HTML: Cache-Control: no-cache — selalu melakukan revalidasi, manfaatkan 304 saat tidak ada perubahan
• Aset statis yang di-version (JS, CSS, gambar dengan hash di nama file): Cache-Control: public, max-age=31536000, immutable
• Aset statis yang tidak di-version (font, favicon): Cache-Control: public, max-age=604800 (1 minggu)
• Respons API (umum, sensitif terhadap waktu): Cache-Control: public, max-age=60, s-maxage=300 — TTL browser pendek, TTL CDN lebih panjang
• Respons API (spesifik untuk pengguna): Cache-Control: private, no-cache
• Data sensitif: Cache-Control: no-store
• Selalu atur Vary: Accept-Encoding ketika menyajikan respons terkompresi secara kondisional

ETag harus diaktifkan secara default untuk apa pun yang disimpan di cache — mereka adalah mekanisme yang membuat revalidasi hemat bandwidth. Sebagian besar server web (Nginx, Apache, Caddy) menghasilkan ETag secara otomatis kecuali Anda menonaktifkannya.

Anda mungkin juga menyukai