Caching Website Bukan Sekadar Menyalakan Plugin: Cara Mengatur Cache Tanpa Menyajikan Konten Kedaluwarsa

Jika website terasa lambat padahal server tidak sedang penuh, masalahnya bisa bukan pada ukuran gambar atau jumlah plugin. Sering kali, browser dan CDN masih harus meminta ulang file yang sebenarnya tidak berubah: CSS, JavaScript, logo, font, bahkan halaman HTML yang sama.

Di sinilah caching membantu. Cache menyimpan salinan respons agar permintaan berikutnya tidak selalu dimulai dari server asal. Hasilnya, waktu tunggu jaringan berkurang dan server tidak perlu mengerjakan hal yang sama berulang-ulang. Namun cache bukan tombol “aktif lalu selesai”. Ia perlu aturan yang membedakan file statis, halaman publik, dan data yang bersifat pribadi.

Cache bekerja dengan aturan, bukan tebakan

Peramban dan cache perantara seperti CDN membaca instruksi dari header HTTP, terutama Cache-Control. Header ini menentukan apakah respons boleh disimpan, berapa lama salinan dianggap masih segar, dan apakah respons perlu diperiksa ulang ke server.

Jika header tersebut tidak diatur, browser tetap dapat menggunakan perilaku caching heuristik. Artinya, browser mencoba menebak sendiri berapa lama sebuah respons layak dipakai. Untuk website yang serius, lebih baik aturan itu ditentukan secara eksplisit daripada menyerahkan keputusan kepada tebakan klien. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching?utm_source=openai))

Selain Cache-Control, ada ETag dan Last-Modified. Keduanya membantu server menjawab, “File ini belum berubah,” tanpa mengirim ulang seluruh isi file. Jika tidak ada perubahan, server dapat mengembalikan status 304 Not Modified dengan ukuran respons yang sangat kecil. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching?utm_source=openai))

Bedakan tiga jenis konten sebelum menentukan durasi

1. File statis yang diberi versi

CSS, JavaScript, font, dan gambar biasanya cocok diberi cache panjang jika URL-nya berubah setiap kali isi file berubah. Contohnya:

app.8f31c2.css
app.1ab94e.js

Karena nama file sudah mengandung versi atau fingerprint, browser boleh menyimpan file tersebut dalam waktu lama. Saat ada perubahan, website memanggil URL baru sehingga browser mengambil salinan baru. Pola ini sering disebut cache busting.

Contoh header yang umum untuk aset berversi:

Cache-Control: public, max-age=31536000, immutable

Angka tersebut setara dengan satu tahun. Jangan menerapkan durasi sepanjang itu pada file yang URL-nya tetap tetapi isinya sering berubah. Jika dilakukan, pengunjung bisa melihat CSS atau JavaScript lama sampai cache kedaluwarsa atau dibersihkan secara manual. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching?utm_source=openai))

2. HTML publik

Halaman artikel atau landing page yang sama untuk semua pengunjung dapat dicache, tetapi durasinya perlu disesuaikan dengan frekuensi pembaruan konten. Website berita mungkin membutuhkan TTL beberapa menit, sedangkan dokumentasi yang jarang berubah bisa lebih lama.

Untuk halaman HTML yang URL-nya tidak bisa diganti seperti aset statis, strategi revalidasi biasanya lebih aman. Dengan Cache-Control: no-cache, browser masih boleh menyimpan respons, tetapi perlu memeriksa ke server sebelum menggunakannya kembali. Jika tidak berubah, server cukup mengirim 304.

Cache-Control: no-cache
ETag: "homepage-v42"
Last-Modified: Wed, 26 Aug 2026 08:00:00 GMT

Perlu dicatat, no-cache bukan berarti “jangan simpan sama sekali”. Jika benar-benar tidak boleh disimpan, gunakan no-store. Perbedaan ini penting karena banyak konfigurasi caching keliru hanya karena kedua istilah tersebut dianggap sama.

3. Halaman pribadi dan data login

Dashboard pengguna, keranjang belanja, halaman akun, dan respons yang dipengaruhi cookie tidak boleh diperlakukan seperti halaman publik. Menyimpan respons tersebut di cache bersama dapat berisiko menampilkan data pengguna A kepada pengguna B.

Untuk respons yang bersifat pribadi, gunakan aturan seperti:

Cache-Control: private, no-cache

Atau, untuk data yang benar-benar tidak boleh disimpan:

Cache-Control: private, no-store

Jika respons berubah berdasarkan cookie, pengaturan cache juga perlu memperhitungkan variasi tersebut. Kesalahan pada bagian ini bukan hanya masalah performa, tetapi juga masalah privasi dan keamanan. ([web.dev](https://web.dev/articles/http-cache-security?hl=en&utm_source=openai))

Stale-while-revalidate: cepat sekarang, diperbarui di belakang layar

Untuk konten yang masih boleh sedikit tertinggal—misalnya daftar artikel terbaru, katalog, atau data cuaca—stale-while-revalidate dapat menjadi pilihan.

Cache-Control: public, max-age=60, stale-while-revalidate=300

Dengan aturan tersebut, respons dianggap segar selama 60 detik. Setelah itu, cache masih dapat menyajikan salinan lama hingga 300 detik sambil meminta versi terbaru ke server di belakang layar. Pengunjung tidak harus menunggu proses pembaruan pada permintaan pertama.

Strategi ini berguna jika sedikit keterlambatan informasi dapat diterima. Jangan menggunakannya untuk saldo rekening, status pembayaran, stok yang sangat terbatas, atau informasi lain yang harus selalu presisi. ([web.dev](https://web.dev/articles/stale-while-revalidate?hl=en&utm_source=openai))

Cache yang salah sering terlihat seperti bug aplikasi

Setelah mengaktifkan caching, beberapa masalah umum dapat muncul:

• Perubahan CSS tidak terlihat karena browser masih menggunakan file lama.
• Pengguna melihat halaman checkout yang sudah kedaluwarsa.
• Artikel baru belum muncul karena cache CDN belum dibersihkan.
• Pengunjung yang sudah login menerima halaman versi anonim, atau sebaliknya.
• Cache di browser sudah diperbarui, tetapi cache di reverse proxy masih menyimpan respons lama.

Karena itu, pengujian harus dilakukan dari beberapa kondisi: jendela incognito, perangkat berbeda, pengguna anonim, dan pengguna yang sudah login. Periksa juga header respons melalui DevTools browser atau perintah seperti curl -I https://contoh.com/. Cari Cache-Control, ETag, usia cache, serta header dari CDN jika digunakan.

Yang bisa dilakukan sekarang

1. Buat inventaris URL penting. Pisahkan aset statis, HTML publik, endpoint API, halaman login, dan checkout.
2. Gunakan URL berversi untuk aset. Jangan memberi cache satu tahun pada file yang namanya selalu sama jika isinya sering berubah.
3. Mulai dengan TTL konservatif. Durasi pendek lebih mudah diperpanjang daripada memperbaiki konten yang telanjur tertahan di banyak cache.
4. Tentukan prosedur purge. Pastikan tim tahu cara membersihkan cache browser, plugin, reverse proxy, dan CDN.
5. Ukur hasilnya. Bandingkan waktu respons, jumlah request ke origin, dan pengalaman pengguna nyata. PageSpeed Insights membedakan data laboratorium dari data lapangan, sementara Core Web Vitals menggunakan metrik seperti LCP, INP, dan CLS untuk menggambarkan pengalaman pengguna. ([developers.google.com](https://developers.google.com/speed/docs/insights/v5/about?authuser=2&hl=en&utm_source=openai))

Apa artinya bagi kita?

Strategi cache yang baik bukan yang membuat semua hal disimpan selama mungkin. Strategi yang baik adalah yang tahu apa yang aman disimpan, berapa lama boleh digunakan, dan kapan harus diperiksa ulang.

Mulailah dari aset statis yang sudah memiliki versi, lalu rapikan aturan untuk HTML publik. Setelah itu, audit halaman pribadi dan endpoint yang menggunakan cookie. Dengan urutan tersebut, caching bisa mengurangi beban server dan mempercepat website tanpa mengorbankan ketepatan konten maupun privasi pengguna.

Sumber & bacaan lebih lanjut

• HTTP caching - MDN Web Docs
• HTTP conditional requests - MDN Web Docs
• Cache-Control header - MDN Web Docs
• Prevent unnecessary network requests with the HTTP Cache - web.dev
• Keeping things fresh with stale-while-revalidate - web.dev
• About PageSpeed Insights - Google for Developers
• Understanding Core Web Vitals and Google search results - Google Search Central

– Rio Yotto @rioyotto