HTTP Caching: Bikin Kunjungan Ulang Situs Lebih Cepat

Permintaan jaringan paling cepat adalah permintaan yang tidak pernah dikirim. Saat pengunjung kembali ke situsmu, browser mereka bisa memakai ulang file yang sudah pernah diunduh, alih-alih mengambilnya lagi. Itulah HTTP caching, dan semuanya diatur oleh beberapa header respons yang sering dibiarkan dengan pengaturan bawaan. Mengaturnya dengan benar adalah salah satu cara termurah untuk mempercepat situs.

Cara kerja HTTP caching

Setiap respons dari server bisa membawa instruksi tentang berapa lama respons itu boleh disimpan dan dipakai ulang. Browser mengikuti instruksi ini, begitu juga cache bersama seperti CDN dan proxy.

Respons yang tersimpan bisa berstatus fresh, artinya langsung boleh dipakai, atau stale, artinya cache perlu mengecek ke server dulu. Aturannya tercantum dalam standar HTTP caching, RFC 9111, dan dirangkum dengan jelas di panduan HTTP caching dari MDN.

Header Cache-Control

Cache-Control adalah header utama yang akan kamu pakai. Berikut direktif yang perlu diketahui:

• max-age=N: respons tetap fresh selama N detik. 31536000 sama dengan satu tahun.

• no-cache: respons boleh disimpan, tetapi wajib divalidasi ulang ke server setiap kali akan dipakai. Meski namanya begitu, artinya bukan "jangan di-cache".

• no-store: jangan simpan respons sama sekali. Pakai untuk data sensitif seperti halaman perbankan.

• public dan private: private membatasi penyimpanan hanya di browser pengguna, sehingga CDN tidak menyimpan salinan halaman pribadi.

• immutable: memberi tahu browser yang mendukung bahwa file tidak akan berubah selama masih fresh, jadi tidak perlu dicek ulang meski halaman di-reload.

Validasi ulang: ETag dan 304 Not Modified

Saat respons yang tersimpan menjadi stale, browser tidak harus mengunduh ulang dari awal. Browser cukup bertanya ke server apakah file sudah berubah.

Server menyertakan ETag, yaitu sidik jari versi file. Di permintaan berikutnya, browser mengirim nilai itu kembali lewat header If-None-Match. Jika tidak ada perubahan, server membalas dengan 304 Not Modified tanpa isi, dan browser memakai salinannya. Tetap ada satu perjalanan bolak-balik ke server, tetapi unduhan file dilewati.

Pengaturan sederhana yang sudah teruji

Sebagian besar situs bisa memakai satu pola yang juga direkomendasikan web.dev dalam panduan mencegah permintaan jaringan yang tidak perlu dengan HTTP cache:

1. File statis berversi: cache selamanya

Build tool bisa menambahkan hash konten ke nama file, misalnya app.3f9a1c.js. Saat kode berubah, namanya ikut berubah, sehingga file lama aman di-cache dalam waktu lama.

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

2. Halaman HTML: selalu validasi ulang

HTML menunjuk ke file berversi terbaru, jadi harus selalu mutakhir.

Cache-Control: no-cache

Dengan kombinasi ini, deploy baru langsung berlaku, sementara pengunjung yang kembali tetap memuat script, style, dan font langsung dari cache mereka.

Tips dan kesalahan umum

1. Jangan beri waktu cache panjang untuk file tanpa versi. Jika style.css di-cache setahun tanpa hash di namanya, pengunjung bisa melihat tampilan lama jauh setelah kamu memperbaruinya.

2. Jauhkan data pribadi dari cache bersama. Gunakan private atau no-store untuk halaman berisi detail akun, atau CDN bisa menyajikan halaman milik satu pengguna ke pengguna lain.

3. Pakai stale-while-revalidate untuk data yang kurang kritis. Direktif ini membuat cache langsung menyajikan respons yang sedikit lama sambil mengambil versi baru di latar belakang. Artikel web.dev tentang stale-while-revalidate menjelaskan kapan cocok dipakai.

4. Cek header di DevTools. Buka panel Network, klik sebuah permintaan, lalu lihat header responsnya. Label "(disk cache)" atau "(memory cache)" berarti cache bekerja dengan baik.

5. Ingat header Vary. Jika respons berubah tergantung header permintaan, misalnya bahasa atau kompresi, Vary memberi tahu cache untuk menyimpan versi terpisah.

Beri versi pada aset, cache selamanya, dan jaga HTML tetap segar.

Jelajahi lebih lanjut

Caching yang baik langsung memperbaiki metrik pemuatan seperti LCP, yang kami bahas dengan bahasa sederhana di panduan Core Web Vitals. Nomor versi juga penting saat rilis, jadi baca penjelasan kami tentang semantic versioning, atau lihat software yang kami bangun di Ryuartistry.