Petakan kebijakan ke sumber daya, bukan ke server
Inventarisasi URL representatif sebelum mengubah header: halaman utama, halaman konten, shell aplikasi, CSS, JavaScript, gambar, font, API, login, akun, checkout, dan unduhan. Untuk masing-masing, catat apakah respons bersifat publik atau dipersonalisasi, apakah URL-nya berubah saat byte-nya berubah, dan seberapa cepat koreksi harus sampai ke pengunjung.
Buat matriks kebijakan dari inventaris tersebut. Aset publik yang di-address berdasarkan konten membutuhkan aturan berbeda dari HTML pada alamat yang stabil. Respons tanpa Cache-Control masih dapat dicache secara heuristik, jadi aturan eksplisit lebih mudah diuji.
Periode di mana respons tersimpan dapat digunakan kembali; max-age memberikannya dalam detik.
Gunakan istilah Cache-Control secara tepat
Cache-Control memberi tahu browser dan cache bersama bagaimana menyimpan dan menggunakan kembali sebuah respons. max-age=N mengizinkan penggunaan ulang selama masih fresh. s-maxage=N menetapkan kesegaran untuk cache bersama dan menimpa max-age di sana, tetapi browser mengabaikan s-maxage. public mengizinkan cache apa pun; private mengizinkan caching di browser namun mencegah penyimpanan pada cache bersama.
no-cache mengizinkan penyimpanan tetapi mengharuskan validasi ke origin sebelum digunakan kembali. no-store berarti cache tidak boleh menyimpan respons tersebut, tetapi bukan kontrol privasi yang lengkap. Gunakan must-revalidate saat menyajikan konten kadaluarsa setelah expiry tidak dapat diterima; origin yang tidak tersedia kemudian dapat menghasilkan 504 daripada fallback kadaluarsa.
Ia menghapus penyimpanan alih-alih hanya meminta pemeriksaan; gunakan hanya untuk respons yang memang tidak boleh disimpan.
Versi aset yang immutable sebelum memberi masa hidup panjang
URL aset yang diberi versi menyertakan fingerprint konten atau versi rilis, seperti app.4f2c.js. Ketika byte aset berubah, terbitkan URL berbeda dan perbarui referensi HTML. Cache melihat sumber daya baru, sehingga pengunjung mengambil aset baru tanpa perlu invalidasi mencapai setiap browser.
Untuk representasi yang tidak akan berubah selama masa kesegarannya, Cache-Control: max-age=31536000, immutable adalah pola praktis. immutable memberi tahu klien yang mendukung untuk tidak melakukan revalidasi kondisional selama masih fresh. Jangan menerapkannya atau max-age satu tahun pada berkas yang bersifat mutable pada URL yang sama. Pertahankan aset fingerprinted sebelumnya sementara HTML yang dicache masih dapat merujuk ke mereka.
HTML memilih URL aset, jadi urutan rilis harus mempertahankan generasi yang direferensikan.
Buat HTML tetap mutakhir melalui validasi, bukan caching panjang
HTML biasanya memiliki URL yang stabil dan berwajah manusia serta berubah dengan konten, referensi aset, feature flag, atau pemberitahuan keamanan. Pola konservatif untuk HTML publik adalah Cache-Control: no-cache dengan ETag dan Last-Modified ketika platform Anda dapat memproduksinya dengan benar. Browser menyimpan badan tetapi menggunakan permintaan kondisional sebelum digunakan kembali; respons yang tidak berubah dapat mengembalikan 304 Not Modified tanpa badan.
ETag mengidentifikasi versi sumber daya. Pada respons yang kadaluarsa, browser dapat mengirimkannya dalam If-None-Match; jika cocok, server membalas 304, jika tidak, server mengirimkan representasi baru. Pedoman RFC menganjurkan keduanya, ETag dan Last-Modified, pada respons 200 bila memungkinkan. no-cache tidak menjamin validasi pada navigasi Back atau Forward karena browser dapat memulihkan snapshot riwayat sesi.
ETag harus berubah ketika representasi berubah; uji ini lintas origin dan deployment.
Pisahkan pengiriman publik dari respons yang dipersonalisasi dan sensitif
Cache bersama, seperti CDN, dapat menggunakan kembali satu respons untuk banyak pengguna. Jangan biarkan cache bersama menggunakan kembali HTML atau data API spesifik akun antar pengguna. Untuk konten yang dipersonalisasi dan mungkin tinggal di browser, kombinasi private, no-cache adalah titik awal yang masuk akal: mencegah penyimpanan bersama dan mengharuskan validasi. Header Set-Cookie saja tidak menghentikan caching.
Untuk respons yang tidak boleh disimpan, gunakan no-store dan tinjau kode aplikasi, aturan CDN, service worker, penyimpanan browser, log, dan halaman error. Header saja bukan program privasi, kepatuhan, atau keamanan pembayaran yang lengkap. Libatkan penilai keamanan, privasi, dan pembayaran yang berkualifikasi untuk menilai alur sensitif dan persyaratan yang berlaku.
Uji proses masuk, keluar, pergantian akun, dan perubahan izin dengan cache browser dan CDN yang sudah hangat.
Luncurkan perubahan cache sebagai rilis yang dapat dibalik
Ambil baseline header dan perilaku badan untuk permintaan tanpa cache dan permintaan berulang. Di staging, terapkan aset yang diberi versi terlebih dahulu, lalu HTML yang mereferensikannya, dan uji HTML yang dicache lama terhadap origin baru. Periksa jalur direct-origin dan CDN jika keduanya ada. Header Network di DevTools harus menunjukkan kebijakan yang dimaksud dan perilaku berulang.
Simpan manifes rilis berisi URL aset, aturan header, dan versi konfigurasi. Jika sebuah rilis menggabungkan berkas klien yang tidak kompatibel, kembalikan HTML dan perilaku aplikasi ke yang kompatibel, tetapi jangan menimpa berkas fingerprinted yang sudah diterbitkan. Arahkan kembali HTML ke generasi known-good dan pertahankan kedua generasi sementara HTML yang dicache mungkin masih memintanya. Purge cache bersama tidak dapat memaksa browser membuang respons yang masih fresh.
Ubah kegagalan uji header, 404 aset, dan mismatch versi menjadi perubahan pada checklist rilis berikutnya.