Cache Website Bukan Sekadar “Aktif”: Cara Menentukan Apa yang Boleh Disimpan

Banyak website sudah memakai cache, tetapi belum tentu menggunakannya dengan benar. Ada yang semua halaman diberi durasi simpan terlalu pendek sehingga server tetap bekerja keras. Ada pula yang menyimpan HTML terlalu lama, lalu perubahan konten tidak segera terlihat oleh pengunjung.

Masalahnya bukan pada cache itu sendiri, melainkan pada keputusan tentang apa yang boleh disimpan, berapa lama, dan siapa yang boleh menggunakannya kembali. Dengan aturan yang tepat, browser, CDN, dan server tidak perlu mengulang pekerjaan yang sama untuk setiap kunjungan.

Cache bekerja seperti rak penyimpanan dekat pintu

Bayangkan sebuah toko yang sering menjual barang yang sama. Daripada mengambil produk dari gudang setiap kali ada pembeli, toko menaruh beberapa barang populer di rak dekat pintu. Pengunjung bisa langsung mengambilnya, sementara gudang tidak terus-menerus bekerja.

Dalam website, “rak” itu bisa berupa cache browser, CDN, reverse proxy, atau cache di sisi server. Jika sebuah file CSS, JavaScript, gambar, atau halaman bisa digunakan ulang, permintaan tidak selalu perlu sampai ke server utama. Hasilnya, waktu respons dan beban origin server dapat berkurang.

Namun, rak tersebut harus diberi label yang jelas. Header HTTP Cache-Control digunakan untuk memberi tahu browser dan cache bersama seperti CDN apakah sebuah respons boleh disimpan, berapa lama dianggap masih segar, serta apakah respons itu bersifat pribadi atau publik. MDN menjelaskan bahwa direktif seperti max-age, private, public, dan no-store memiliki fungsi yang berbeda.

Bedakan aset statis, HTML, dan data pribadi

Kesalahan paling umum adalah menerapkan satu aturan cache untuk semua jenis respons. Padahal, file logo dan halaman checkout memiliki kebutuhan yang sangat berbeda.

1. Aset statis yang memakai versi

File seperti CSS, JavaScript, font, dan gambar biasanya cocok diberi masa cache panjang—terutama jika namanya berubah setiap kali isinya berubah. Contohnya:

app.2026-10-22.js
style.a81f3c.css

Jika isi file berubah, nama file juga berubah. Browser dapat menyimpan versi lama untuk waktu lama karena versi baru akan dipanggil dengan URL berbeda. Pola ini lebih aman daripada memaksa browser menebak apakah file lama masih berlaku.

Untuk aset yang benar-benar memiliki versi, aturan seperti public, max-age=31536000, immutable sering masuk akal. Angka tersebut setara dengan satu tahun. Tetapi jangan memakainya pada file yang URL-nya tetap sementara isinya sering berubah.

2. HTML publik

Halaman artikel, dokumentasi, atau landing page dapat di-cache, tetapi durasinya biasanya lebih pendek daripada aset statis. Misalnya, HTML bisa disimpan selama beberapa menit lalu divalidasi kembali ke server.

Di sini no-cache sering disalahpahami. Direktif ini bukan berarti “jangan simpan”. Artinya, respons boleh disimpan, tetapi harus divalidasi kembali sebelum digunakan. Ini berbeda dari no-store, yang meminta cache untuk tidak menyimpan respons sama sekali.

3. Halaman dan respons yang berisi data pengguna

Dashboard, keranjang belanja, halaman profil, dan respons yang berubah berdasarkan cookie atau sesi login harus diperlakukan lebih hati-hati. Untuk respons yang hanya boleh digunakan oleh pengguna yang sama, gunakan private. Untuk data yang sangat sensitif dan tidak boleh tersimpan di cache, pertimbangkan no-store.

Risikonya bukan hanya pengguna melihat data lama. Jika respons yang dipersonalisasi masuk ke cache publik tanpa aturan yang benar, ada kemungkinan respons tersebut disajikan kepada pengguna lain. Panduan keamanan cache dari web.dev menyarankan agar respons yang bergantung pada cookie diberi aturan private atau menggunakan kunci cache yang sesuai melalui Vary.

Jangan memakai no-store sebagai obat untuk semua masalah

Menambahkan Cache-Control: no-store memang terasa aman karena browser tidak menyimpan respons. Tetapi pada halaman publik, aturan ini dapat menghilangkan manfaat cache dan membuat navigasi berulang lebih berat.

Selain HTTP cache, browser modern juga memiliki back/forward cache atau bfcache. Fitur ini memungkinkan halaman dipulihkan hampir seketika ketika pengguna menekan tombol kembali atau maju. Dokumentasi web.dev mencatat bahwa penggunaan no-store pada halaman dapat membuatnya tidak memenuhi syarat bfcache pada sejumlah kondisi.

Karena itu, bedakan kebutuhan “harus selalu divalidasi” dengan “tidak boleh disimpan sama sekali”. Untuk halaman publik yang perlu tetap diperiksa, no-cache atau max-age=0 bisa lebih tepat daripada no-store.

Cara memeriksa apakah aturan cache benar-benar bekerja

1. Pilih beberapa URL perwakilan. Uji satu halaman artikel, satu aset JavaScript, dan satu halaman yang membutuhkan login. Jangan hanya menguji beranda.
2. Buka panel Network di DevTools. Periksa header respons, terutama Cache-Control, ETag, Last-Modified, dan informasi apakah respons berasal dari cache.
3. Uji kunjungan kedua. Permintaan pertama belum cukup. Muat ulang halaman, buka ulang tab, lalu gunakan tombol kembali. Perilaku cache sering baru terlihat pada kunjungan berikutnya.
4. Uji setelah perubahan konten. Publikasikan perubahan kecil dan pastikan aset baru atau HTML terbaru benar-benar tampil. Jika perlu menghapus cache CDN setiap kali menerbitkan artikel, mungkin strategi invalidasinya belum rapi.
5. Uji kondisi login dan logout. Pastikan halaman yang berisi nama, keranjang, atau status akun tidak muncul setelah berpindah pengguna atau perangkat.

Hubungannya dengan Core Web Vitals

Cache bukan satu-satunya faktor performa, tetapi cache yang sehat dapat mengurangi waktu tunggu jaringan dan pekerjaan server. Dampaknya bisa membantu pengalaman pengguna, terutama pada kunjungan berulang atau pengguna yang berada jauh dari server utama.

Untuk menilai hasilnya, perhatikan tiga Core Web Vitals: LCP untuk kecepatan munculnya konten utama, INP untuk respons setelah interaksi, dan CLS untuk kestabilan tata letak. Target “baik” yang umum dipakai pada persentil ke-75 adalah LCP maksimal 2,5 detik, INP maksimal 200 milidetik, dan CLS maksimal 0,1. Namun, angka laboratorium saja tidak cukup; uji juga dari data pengguna nyata dan perangkat yang lebih lambat. Web.dev merangkum definisi dan ambang tersebut.

Yang bisa dilakukan sekarang

• Buat aturan cache terpisah untuk aset statis, HTML publik, dan halaman pengguna.
• Gunakan nama file berversi untuk CSS dan JavaScript yang ingin disimpan lama.
• Jangan menyimpan respons personal ke cache publik.
• Gunakan no-store hanya ketika memang diperlukan, bukan sebagai pengganti desain cache yang jelas.
• Periksa header melalui DevTools dan lakukan pengujian setelah setiap perubahan konfigurasi CDN atau server.

Cache yang baik bukan cache yang menyimpan semuanya selama mungkin. Cache yang baik adalah cache yang tahu kapan harus melayani salinan lama, kapan harus memvalidasi ulang, dan kapan harus benar-benar mengambil data baru. Begitu pembagian ini jelas, website biasanya menjadi lebih cepat tanpa mengorbankan ketepatan informasi atau privasi pengguna.

Sumber & bacaan lebih lanjut

• Cache-Control header - HTTP | MDN
• HTTP caching - MDN
• Improve security and privacy by updating HTTP Cache - web.dev
• Back/forward cache - web.dev
• How the Core Web Vitals metrics thresholds were defined - web.dev

– Rio Yotto @rioyotto