Ketika artikel sudah diperbarui tetapi pembaca masih melihat versi lama, cari lapisan yang menyajikannya sebelum mematikan seluruh cache. Browser, CDN, service worker, dan aplikasi dapat menyimpan respons dengan aturan berbeda. Menghapus satu lapisan belum tentu memperbarui lapisan lainnya.
Cache membantu memakai kembali respons sehingga tidak selalu perlu mengunduh dan menghasilkan ulang resource. Masalahnya muncul ketika kebijakan penyimpanan tidak cocok dengan cara konten berubah. Kita perlu menjaga kecepatan sekaligus memastikan pembaca menerima versi yang seharusnya.
Simpan bukti sebelum dan sesudah perubahan melalui perbandingan snapshot teknis setelah rilis agar versi respons yang diuji dapat ditelusuri.
Tetapkan bukti versi yang diharapkan
Ambil satu URL yang bermasalah. Catat perubahan spesifik, misalnya satu kalimat yang diperbaiki atau nama file CSS yang baru. Simpan waktu rilis dan versi build. Jangan memakai tanggal di footer sebagai satu-satunya penanda karena tanggal itu bisa dihasilkan terpisah.
Periksa HTML yang diterima dan halaman yang akhirnya ditampilkan. Jika HTML sudah baru tetapi tampilan tetap lama, penyebabnya mungkin aset, kode aplikasi, atau service worker. Jika HTML sendiri masih lama, pemeriksaan dimulai dari jalur penyajian dokumen.
Jangan langsung menyimpulkan Google menyimpan halaman lama. Pertama, buktikan respons yang sekarang diterima pembaca dari website sendiri.
Baca instruksi cache sesuai artinya
max-age menyatakan masa kesegaran respons. no-cache mengharuskan validasi sebelum respons dipakai kembali sesuai mekanisme HTTP; ia bukan larangan menyimpan. no-store melarang penyimpanan respons, sedangkan private membatasi penyimpanan pada cache pribadi. Standar HTTP Caching.
Validator seperti ETag dan Last-Modified membantu memeriksa apakah representasi berubah. Respons 304 Not Modified berarti salinan yang dimiliki dapat dipakai untuk permintaan bersyarat tersebut; status itu bukan error halaman. Panduan HTTP caching.
Periksa aturan CDN yang benar-benar aktif. Layanan terkelola bisa mempunyai konfigurasi dan mekanisme purge tersendiri. Header browser saja belum menjelaskan seluruh keputusan cache di infrastruktur.
Pisahkan kunjungan baru dan kunjungan ulang
Gunakan panel Network untuk melihat respons dokumen dan aset. Lakukan pemeriksaan terkontrol pada profil uji tanpa menghapus data pengguna lain.
| Percobaan | Yang dicatat | Pertanyaan |
|---|---|---|
| Kunjungan awal pada profil uji bersih | Body versi, status, header | Apa yang diterima tanpa salinan lokal sebelumnya? |
| Kunjungan ulang biasa | Sumber memory/disk atau respons jaringan | Apakah browser memakai kembali versi yang tepat? |
| Cache browser dinonaktifkan saat debugging | Respons jaringan dan penanda versi | Apakah versi lama tetap datang dari luar browser? |
| Sesudah invalidasi terarah yang disetujui | Body dan header baru | Apakah lapisan yang ditangani memang penyebabnya? |
Menonaktifkan cache pada DevTools berguna untuk diagnosis, tetapi bukan pengalaman kunjungan ulang biasa. Hard reload juga tidak otomatis menghapus salinan di CDN. Jika service worker terpasang, periksa cakupannya secara terpisah.
Simpan header seperti Cache-Control, ETag, Last-Modified, Age, dan header status CDN yang tersedia. Nilai Age atau status hit membantu membaca jalur respons, tetapi interpretasinya tetap mengikuti layanan yang digunakan.
Contoh: HTML baru memakai CSS lama
Misalnya website mengganti isi /assets/site.css pada setiap rilis tetapi tetap memakai URL yang sama. Browser sebelumnya diberi masa cache panjang. HTML baru kemudian meminta URL lama itu dan browser masih mempunyai salinan yang dianggap segar. Ini contoh ilustratif.
Salah satu desain yang dapat dipertimbangkan adalah memberi nama aset berdasarkan versi atau hash isi, misalnya site.a1b2.css. Ketika isi berubah, URL aset berubah. HTML yang baru menunjuk nama baru, sementara aset lama tetap tersedia bagi dokumen lama yang masih memerlukannya.
Desain tersebut perlu diterapkan oleh proses build secara konsisten. Mengganti nama satu file secara manual tanpa memperbarui semua pemanggil dapat membuat aset hilang. Jangan menghapus aset rilis sebelumnya sebelum memahami kebutuhan dokumen yang masih tersimpan.
Jika perubahan mendesak hanya pada satu URL, invalidasi terarah pada cache yang relevan dapat membantu. Pastikan ada izin penerapan dan periksa hasilnya. Purge seluruh situs bukan langkah pertama otomatis karena dapat menambah beban origin.
Pilih kebijakan menurut perubahan resource
| Resource | Pertanyaan desain | Arah keputusan |
|---|---|---|
| HTML artikel yang dapat dikoreksi | Seberapa cepat koreksi harus terlihat? | Validasi atau masa cache yang sesuai proses editorial |
| CSS/JS dengan nama berdasarkan isi | Apakah URL berubah ketika isi berubah? | Cache panjang dapat dipertimbangkan bila kontraknya benar |
| Gambar yang diganti pada URL sama | Apakah pembaca lama harus melihat pengganti segera? | Versi URL atau invalidasi yang terencana |
| Halaman personal | Apakah respons khusus satu pengguna? | Jangan membagikannya melalui cache publik |
Tidak ada satu angka masa cache yang cocok untuk semua jenis resource. Pilih berdasarkan mekanisme pembaruan, kebutuhan pengguna, dan kemampuan pemulihan.
Verifikasi setelah perbaikan
Ulangi kunjungan awal dan kunjungan ulang. Periksa bahwa isi, gambar, navigasi, serta fungsi utama memakai versi yang cocok. Jika validator dipakai, pastikan perubahan isi menghasilkan representasi baru yang benar, bukan 304 berdasarkan penanda yang tidak ikut berubah.
Catat lapisan penyebab, perubahan kebijakan, URL yang diuji, dan hasilnya. Keberhasilan satu URL belum membuktikan semua template aman bila aturan cache-nya berbeda.
Langkah pertama yang bisa kamu ambil adalah memilih satu perubahan yang belum terlihat, lalu membandingkan body HTML pada profil bersih dan kunjungan ulang. Bukti itu akan menunjukkan apakah pemeriksaan berikutnya menuju browser, CDN, aset, atau aplikasi.
