Cache busting JavaScript dan CSS: versi berkas serta rilis yang aman
Cache busting memberi JavaScript atau CSS yang berubah sebuah URL baru, biasanya dengan hash konten pada nama berkas. Berkas berversi dapat disimpan lama, sedangkan HTML perlu menemukan rilis baru melalui masa segar pendek atau validasi ulang.
Dalam panduan ini
Jika rilis terlihat baru di jendela privat tetapi lama pada kunjungan ulang, bandingkan URL aset dahulu. Server mungkin sudah mengganti berkas, sementara peramban masih memiliki respons segar untuk URL sebelumnya. Mengubah semua cache sekaligus dapat menyembunyikan sumber masalah.
Rilis yang andal menjelaskan hubungan HTML dengan asetnya. Contoh mempertahankan versi lama dan baru sehingga halaman yang terbuka sebelum rilis masih bisa mengambil berkas yang cocok.
Pisahkan dokumen HTML dari aset berversi
HTML dapat dipandang sebagai manifest kecil. Rilis A menunjuk app.4c21.js dan site.19ab.css. Rilis B mengubah aplikasi menjadi app.9d80.js; CSS yang byte-nya tetap dapat memakai site.19ab.css. Nama hash ini ilustrasi, bukan hasil perhitungan berkas nyata.
Aset yang tetap dapat dipakai kembali, sementara perubahan memperoleh identitas cache baru. Jika HTML disimpan segar terlalu lama, pengunjung terus mendapatkan dokumen yang menunjuk URL lama dan belum mengetahui rilis baru.
| Sumber daya | Rilis A | Rilis B | Perlakuan yang diharapkan |
|---|---|---|---|
| Dokumen HTML | Menunjuk app.4c21.js | Menunjuk app.9d80.js | Validasi ulang atau masa segar yang sengaja pendek |
| JavaScript aplikasi | app.4c21.js | app.9d80.js | URL baru ketika byte berubah |
| CSS tidak berubah | site.19ab.css | site.19ab.css | Pakai kembali URL konten yang sama |
| Aset sebelumnya | Tersedia | Tetap tersedia bagi halaman lama | Pertahankan selama jendela kompatibilitas |
Cocokkan direktif cache dengan kesepakatan tersebut
Untuk aset publik yang tidak akan berubah pada URL itu, max-age panjang dengan immutable bisa sesuai. Pada HTML, no-cache membolehkan penyimpanan tetapi mewajibkan validasi sebelum dipakai kembali. Ini berbeda dari no-store yang meminta cache tidak menyimpan respons. Jangan menyalin satu kebijakan untuk semua sumber daya.
Header berikut hanya contoh strategi. Periksa header yang benar-benar dikirim hosting dan aturan cache CDN. Baris konfigurasi lokal tidak membuktikan peramban publik atau edge menerima kebijakan yang sama.
Versioned public asset: /assets/app.9d80.js
Cache-Control: public, max-age=31536000, immutable
HTML document: /index.html
Cache-Control: no-cache
The URL /assets/app.9d80.js must continue to serve the same bytes.Versi dalam query bekerja bila masuk kunci cache
Alamat /app.js?v=release-b bisa menjadi identitas berbeda dari /app.js?v=release-a. Pastikan setiap lapisan penting memasukkan parameter itu ke cache key. Aturan CDN yang mengabaikan query dapat membuat keduanya memakai objek cache sama.
Jangan menambahkan nilai acak setiap pemuatan. URL unik untuk setiap kunjungan menghilangkan manfaat penggunaan ulang. Hash atau versi rilis seharusnya berubah ketika sumber daya berubah. Fragmen /app.js#release-b tidak dikirim dalam permintaan HTTP dan tidak cocok untuk tujuan ini.
Temukan lapisan yang mengirim byte lama
Bandingkan respons HTML, URL aset rujukannya, dan byte aset pada kunjungan bermasalah. Rujukan hash lama mengarah pada kesegaran HTML. Hash baru dengan isi lama mengarah pada deployment, cache key, atau origin. Bila jaringan benar tetapi perilaku lama bertahan, periksa halaman yang sudah berjalan dan service worker.
Purge CDN tidak menghapus respons segar di semua peramban. Hard reload hanya diagnosis lokal, bukan perbaikan untuk seluruh pengunjung. Catat cache mana yang dilewati pada setiap pengujian agar keberhasilannya dapat diulang.
- Catat URL HTML akhir dan URL skrip atau stylesheet yang dirujuk.
- Periksa status, Content-Type, Cache-Control, ETag, serta header status cache yang tersedia.
- Pastikan versi yang diminta mengembalikan byte yang benar, bukan halaman HTML cadangan.
- Periksa aturan cache service worker secara terpisah jika dipasang.
- Uji kunjungan bersih dan halaman yang tetap terbuka selama rilis.
Jaga halaman lama dan kemampuan rollback
Unggah aset baru sebelum HTML yang merujuknya, atau gunakan deployment yang mengalihkan satu rilis lengkap sekaligus. Simpan aset sebelumnya selama HTML lama dan tab terbuka masih mungkin memakainya. Sebuah halaman bisa meminta modul tambahan jauh setelah kunjungan awal.
Terbitkan B dengan aset A dan B tersedia, verifikasi B, lalu pertahankan pilihan mengarahkan HTML kembali ke A. Menghapus app.4c21.js segera dapat merusak halaman A. Memakai nama itu untuk byte baru juga melanggar identitas konten dan membuat rollback sulit diprediksi.
Ukur penggunaan ulang setelah rilis benar
Uji kunjungan awal, kunjungan ulang, lalu rilis baru. Yang pertama mengunduh aset; berikutnya dapat menggunakan respons yang memenuhi kebijakan; rilis baru mengambil versi yang berubah. Periksa transfer nyata termasuk validasi ulang, bukan menganggap semua respons cache sama.
Kalkulator penghematan cache memperkirakan pengurangan permintaan origin dari asumsi hit rate Anda. Kalkulator transfer menghubungkan jumlah permintaan dengan ukuran respons. Gunakan untuk membandingkan rencana yang eksplisit, lalu tetap ukur header publik dan hit rate sebenarnya.
Pertanyaan umum
Haruskah semua cache dimatikan untuk memperbarui CSS?
Biasanya cari dokumen atau aset yang usang dahulu dan terapkan versi stabil. Mematikan penggunaan ulang menambah transfer serta latensi tanpa memperjelas proses rilis.
Apakah ETag baru langsung mengganti berkas segar?
Peramban dapat memakai respons selama masih segar tanpa meminta validasi. URL konten baru menghindari ketergantungan pada validasi masa depan bagi aset yang berubah.
Kapan aset dengan hash lama boleh dihapus?
Setelah jendela kompatibilitas yang dibutuhkan HTML tersimpan, halaman terbuka, dan rollback. Pertahankan berkas selama dokumen yang didukung masih dapat merujuknya.
Sumber & definisi
Metode diperiksa: