Strategi Caching: Kapan Ambil dari Cache, Kapan ke Server

Kulkas, pasar, dan pesan antar

Kamu butuh bahan masakan. Tiga strategi: cek kulkas dulu (kalau ada, tidak perlu ke pasar), langsung ke pasar (selalu segar, tapi lama), atau pakai stok kulkas sambil memesan yang baru (cepat DAN segar menyusul). Tiga pola caching HTTP bekerja dengan logika yang sama.

Kenapa satu strategi tidak cukup

File CSS tidak berubah berminggu-minggu: ambil dari cache selalu (cepat). Data saldo bank berubah tiap detik: selalu ke server (akurat). Feed berita: tampilkan cache dulu agar instan, lalu perbarui diam-diam di background. Strategi yang tepat tergantung seberapa cepat data basi dan seberapa parah akibatnya kalau basi.

Contoh 1: cache-first untuk aset statis

HTTP/1.1 200 OK
Cache-Control: public, max-age=31536000, immutable

/* app.a1b2c3.css */

Browser tidak pernah bertanya ke server selama setahun. Strategi ini hanya aman untuk file dengan nama ber-hash: konten baru berarti nama baru, jadi cache lama tidak mungkin salah.

Contoh 2: stale-while-revalidate untuk konten dinamis

HTTP/1.1 200 OK
Cache-Control: public, max-age=60, stale-while-revalidate=300

{"headline": "..."}

Artinya: "pakai cache sampai 60 detik. Setelah itu, tampilkan cache basi sambil ambil versi baru di background (toleransi 300 detik)." User selalu melihat sesuatu dengan instan, dan data perlahan menyusul. Pola ini populer untuk halaman berita dan katalog.

Untuk data kritis (saldo, stok checkout), pakai network-first: selalu ke server, cache hanya sebagai cadangan saat offline.

Kesalahan umum

Salah: satu strategi untuk semua. API saldo di-cache 1 jam membuat user melihat angka salah. Yang benar: petakan tiap jenis data ke strategi yang sesuai.

Salah: lupa memikirkan invalidasi. Data berubah di server tapi cache masih menyajikan versi lama. Yang benar: untuk perubahan penting, pakai versioning nama file atau purge cache CDN.

Salah: tidak menangani mode offline. Network-first tanpa fallback membuat aplikasi mati total saat offline. Yang benar: selalu sediakan fallback cache untuk pengalaman offline minimal.

Matriks keputusan cepat

Cetak matriks ini. Setiap kali membuat endpoint baru, tentukan barisnya dalam 10 detik. Keputusan caching yang konsisten sejak awal mencegah bug "data basi" yang sulit dilacak.

Catatan teknis: Service worker memungkinkan strategi caching custom di sisi klien, termasuk background sync. Library Workbox menyediakan pola siap pakai (CacheFirst, NetworkFirst, StaleWhileRevalidate) tanpa menulis logika manual.