Mencegah permintaan jaringan yang tidak perlu dengan Cache HTTP

Ilya Grigorik
Twitter Halaman beranda
Jeff Posnick

Mengambil resource melalui jaringan lambat dan mahal:

  • Respons yang besar memerlukan banyak bolak-balik antara browser dan server.
  • Halaman Anda tidak akan dimuat sampai semua resource pentingnya selesai didownload.
  • Jika seseorang mengakses situs Anda dengan paket data seluler terbatas, setiap permintaan jaringan yang tidak perlu akan sia-sia.

Bagaimana Anda dapat menghindari permintaan jaringan yang tidak perlu? Cache HTTP browser adalah baris pertahanan pertama Anda. Cara ini bukan pendekatan yang paling ampuh atau fleksibel, dan Anda memiliki kontrol terbatas atas masa aktif respons yang di-cache, tetapi cara ini efektif, karena didukung di semua browser dan tidak memerlukan banyak upaya.

Panduan ini menunjukkan dasar-dasar penerapan cache HTTP yang efektif.

Kompatibilitas browser

Sebenarnya tidak ada satu API yang disebut {i>Cache HTTP<i}. Ini adalah nama umum untuk kumpulan API platform web. API tersebut didukung di semua browser:

Cara kerja Cache HTTP

Semua permintaan HTTP yang dibuat browser akan dirutekan terlebih dahulu ke cache browser untuk memeriksa apakah ada respons valid yang di-cache yang dapat digunakan untuk memenuhi permintaan tersebut. Jika ada kecocokan, respons akan dibaca dari cache, yang menghilangkan latensi jaringan dan biaya data yang ditimbulkan oleh transfer.

Perilaku Cache HTTP dikontrol oleh kombinasi header permintaan dan header respons. Dalam skenario ideal, Anda akan memiliki kontrol atas kode untuk aplikasi web Anda (yang akan menentukan header permintaan) dan konfigurasi server web Anda (yang akan menentukan header respons).

Baca artikel Cache HTTP MDN untuk ringkasan konseptual yang lebih mendalam.

Header permintaan: tetap menggunakan default (biasanya)

Meskipun ada sejumlah header penting yang harus disertakan dalam permintaan keluar aplikasi web Anda, browser hampir selalu menangani setelannya untuk Anda saat membuat permintaan. Header permintaan yang memengaruhi pemeriksaan keaktualan, seperti If-None-Match dan If-Modified-Since akan muncul berdasarkan pemahaman browser tentang nilai saat ini di Cache HTTP.

Ini berarti Anda dapat terus menyertakan tag seperti <img src="my-image.png"> di HTML, dan browser akan otomatis menangani caching HTTP untuk Anda tanpa upaya tambahan.

Header respons: mengonfigurasi server web Anda

Bagian dari penyiapan caching HTTP yang paling penting adalah header yang ditambahkan server web Anda ke setiap respons keluar. Semua header berikut diperhitungkan dalam perilaku caching yang efektif:

  • Cache-Control. Server dapat menampilkan perintah Cache-Control untuk menentukan cara dan durasi browser dan cache perantara lainnya harus meng-cache respons individual.
  • ETag. Jika menemukan respons yang di-cache sudah tidak berlaku, browser dapat mengirim token kecil (biasanya hash konten file) ke server untuk memeriksa apakah file telah berubah. Jika server menampilkan token yang sama, berarti filenya sama, dan tidak perlu mendownload ulang.
  • Last-Modified. Header ini memiliki tujuan yang sama dengan ETag, tetapi menggunakan strategi berbasis waktu untuk menentukan apakah resource telah berubah, bukan strategi berbasis konten ETag.

Beberapa server web memiliki dukungan bawaan untuk menyetel header tersebut secara default, sementara yang lain tidak menyertakan header sepenuhnya kecuali jika Anda mengonfigurasinya secara eksplisit. Detail spesifik tentang cara mengonfigurasi header sangat bervariasi, bergantung pada server web yang Anda gunakan, dan Anda harus membaca dokumentasi server untuk mendapatkan detail yang paling akurat.

Untuk menghemat penelusuran, berikut adalah petunjuk cara mengonfigurasi beberapa server web populer:

Membiarkan header respons Cache-Control tidak disertakan dalam cache HTTP tidak dinonaktifkan. Sebaliknya, browser secara efektif menebak jenis perilaku caching yang paling sesuai untuk jenis konten tertentu. Kemungkinan Anda menginginkan lebih banyak kontrol daripada yang ditawarkan, jadi luangkan waktu untuk mengonfigurasi header respons Anda.

Nilai header respons mana yang harus Anda gunakan?

Ada dua skenario penting yang harus Anda bahas saat mengonfigurasi header respons server web.

Cache aktif untuk URL berversi

Cara URL berversi dapat membantu strategi penyimpanan cache Anda
URL versi adalah praktik yang baik karena mempermudah pembatalan respons yang di-cache.

Misalnya server Anda memerintahkan browser untuk menyimpan file CSS ke dalam cache selama 1 tahun (Cache-Control: max-age=31536000), tetapi desainer Anda baru saja membuat update darurat yang harus segera diluncurkan. Bagaimana cara memberi tahu browser untuk memperbarui salinan file yang di-cache yang "tidak berlaku"? Anda tidak dapat melakukannya, setidaknya tanpa mengubah URL resource. Setelah browser meng-cache respons, versi yang di-cache akan digunakan hingga tidak lagi baru, seperti yang ditentukan oleh max-age atau expires, atau hingga dikeluarkan dari cache karena alasan lain—misalnya, pengguna menghapus cache browsernya. Akibatnya, pengguna yang berbeda mungkin akhirnya menggunakan versi file yang berbeda saat halaman dibuat: pengguna yang baru saja mengambil resource akan menggunakan versi baru, sedangkan pengguna yang meng-cache salinan sebelumnya (tetapi masih valid) akan menggunakan respons versi lama. Bagaimana cara Anda mendapatkan yang terbaik dari kedua hal tersebut: caching sisi klien dan update cepat? Anda dapat mengubah URL resource dan memaksa pengguna mendownload respons baru setiap kali kontennya berubah. Biasanya, Anda melakukannya dengan menyematkan sidik jari file, atau nomor versi, dalam nama filenya—misalnya, style.x234dff.css.

Saat merespons permintaan untuk URL yang berisi "sidik jari" atau informasi pembuatan versi, dan yang kontennya tidak pernah dimaksudkan untuk berubah, tambahkan Cache-Control: max-age=31536000 ke respons Anda.

Menyetel nilai ini akan memberi tahu browser bahwa saat browser perlu memuat URL yang sama kapan saja selama satu tahun ke depan (31.536.000 detik; nilai maksimum yang didukung), browser dapat langsung menggunakan nilai dalam Cache HTTP, tanpa harus membuat permintaan jaringan ke server web Anda sama sekali. Itu bagus—Anda telah segera mendapatkan keandalan dan kecepatan yang diperoleh dengan menghindari jaringan.

Alat build seperti webpack dapat mengotomatiskan proses penetapan sidik jari hash ke URL aset Anda.

Validasi ulang server untuk URL tidak versi

Sayangnya, tidak semua URL yang Anda muat memiliki versi. Mungkin Anda tidak dapat menyertakan langkah build sebelum men-deploy aplikasi web, sehingga tidak dapat menambahkan hash ke URL aset. Dan setiap aplikasi web memerlukan file HTML. File tersebut (hampir) tidak akan pernah menyertakan informasi pembuatan versi, karena tidak ada yang akan terganggu menggunakan aplikasi web Anda jika mereka perlu mengingat bahwa URL yang akan dikunjungi adalah https://example.com/index.34def12.html. Jadi, apa yang dapat Anda lakukan untuk URL tersebut?

Ini adalah salah satu skenario di mana Anda perlu mengaku kekalahan. {i>Cache<i} HTTP saja tidak cukup bertenaga untuk menghindari jaringan sepenuhnya. (Jangan khawatir—Anda akan segera mempelajari pekerja layanan, yang akan memberikan dukungan yang kami butuhkan untuk bertempur sesuai keinginan Anda.) Namun, ada beberapa langkah yang dapat Anda ambil untuk memastikan permintaan jaringan berjalan secepat dan seefisien mungkin.

Nilai Cache-Control berikut dapat membantu Anda menyesuaikan lokasi dan cara URL tanpa versi di-cache:

  • no-cache. Tindakan ini akan memerintahkan browser agar browser harus melakukan validasi ulang dengan server setiap saat sebelum menggunakan versi URL yang di-cache.
  • no-store. Ini menginstruksikan browser dan cache perantara lainnya (seperti CDN) untuk tidak pernah menyimpan versi file apa pun.
  • private. Browser dapat meng-cache file, tetapi cache perantara tidak dapat melakukannya.
  • public. Responsnya dapat disimpan oleh cache apa pun.

Lihat Lampiran: Diagram alir Cache-Control untuk memvisualisasikan proses menentukan nilai Cache-Control yang akan digunakan. Perhatikan juga bahwa Cache-Control dapat menerima daftar perintah yang dipisahkan koma. Lihat Lampiran: Contoh Cache-Control.

Selain itu, menyetel salah satu dari dua header respons tambahan juga dapat membantu: ETag atau Last-Modified. Seperti yang disebutkan dalam Header respons, ETag dan Last-Modified memiliki fungsi yang sama: menentukan apakah browser perlu mendownload ulang file cache yang telah habis masa berlakunya. ETag adalah pendekatan yang direkomendasikan karena lebih akurat.

Contoh ETag

Asumsikan bahwa 120 detik telah berlalu sejak pengambilan awal dan browser telah memulai permintaan baru untuk resource yang sama. Pertama-tama, browser akan memeriksa Cache HTTP dan menemukan respons sebelumnya. Sayangnya, browser tidak dapat menggunakan respons sebelumnya karena respons telah berakhir. Pada tahap ini, browser dapat mengirimkan permintaan baru dan mengambil respons penuh baru. Namun, hal ini tidak efisien karena jika resource tidak berubah, tidak ada alasan untuk mendownload informasi yang sama yang sudah ada di cache. Itulah masalah yang didesain untuk dipecahkan oleh token validasi, sebagaimana yang ditetapkan dalam header ETag. Server menghasilkan dan menampilkan token arbitrer, yang biasanya berupa hash atau sidik jari lainnya dari konten file. Browser tidak perlu mengetahui cara sidik jari dihasilkan; browser hanya perlu mengirimkannya ke server pada permintaan berikutnya. Jika sidik jari masih sama, berarti resource belum berubah dan browser dapat melewati download.

Dengan menetapkan ETag atau Last-Modified, Anda akan membuat permintaan validasi ulang jauh lebih efisien. Akhirnya, permintaan tersebut memicu header permintaan If-Modified-Since atau If-None-Match yang disebutkan dalam Header permintaan.

Saat server web yang dikonfigurasi dengan benar melihat header permintaan masuk tersebut, server web dapat mengonfirmasi apakah versi resource yang telah dimiliki browser dalam Cache HTTP-nya cocok dengan versi terbaru di server web. Jika ada kecocokan, server dapat merespons dengan respons HTTP 304 Not Modified, yang setara dengan "Hei, tetap gunakan apa yang sudah Anda miliki!" Ada sangat sedikit data untuk ditransfer saat mengirim jenis respons ini, jadi biasanya jauh lebih cepat daripada harus benar-benar mengirim kembali salinan resource sebenarnya yang diminta.

Diagram klien yang meminta resource dan server merespons dengan header 304.
Browser meminta /file dari server dan menyertakan header If-None-Match untuk memerintahkan server agar hanya menampilkan file lengkap jika ETag file di server tidak cocok dengan nilai If-None-Match browser. Dalam kasus ini, 2 nilai tersebut cocok, sehingga server menampilkan respons 304 Not Modified beserta petunjuk tentang berapa lama file harus di-cache (Cache-Control: max-age=120).

Ringkasan

Cache HTTP adalah cara efektif untuk meningkatkan performa pemuatan karena mengurangi permintaan jaringan yang tidak perlu. Fitur ini didukung di semua browser dan tidak terlalu membutuhkan pekerjaan besar untuk menyiapkannya.

Konfigurasi Cache-Control berikut merupakan awal yang baik:

  • Cache-Control: no-cache untuk resource yang harus divalidasi ulang dengan server sebelum setiap penggunaan.
  • Cache-Control: no-store untuk resource yang tidak boleh di-cache.
  • Cache-Control: max-age=31536000 untuk resource berversi.

Dan header ETag atau Last-Modified dapat membantu Anda memvalidasi ulang resource cache yang telah habis masa berlakunya dengan lebih efisien.

Pelajari lebih lanjut

Jika Anda ingin mengetahui lebih lanjut tentang penggunaan header Cache-Control, lihat panduan Praktik terbaik cache & gotcha max-age dari Jake Archibald.

Lihat Menyukai cache Anda untuk mendapatkan panduan tentang cara mengoptimalkan penggunaan cache untuk pengunjung yang kembali.

Lampiran: Tips lainnya

Jika Anda memiliki lebih banyak waktu, berikut adalah cara lain untuk mengoptimalkan penggunaan Cache HTTP Anda:

  • Gunakan URL yang konsisten. Jika Anda menayangkan konten yang sama di URL berbeda, konten tersebut akan diambil dan disimpan beberapa kali.
  • Minimalkan churn. Jika bagian dari resource (seperti file CSS) sering diperbarui, sedangkan file lainnya tidak (seperti kode library), pertimbangkan untuk membagi kode yang sering diperbarui ke dalam file terpisah dan menggunakan strategi caching yang berdurasi singkat untuk kode yang sering diperbarui dan strategi durasi caching yang panjang untuk kode yang tidak sering berubah.
  • Lihat perintah stale-while-revalidate baru jika beberapa tingkat data tidak berlaku dapat diterima dalam kebijakan Cache-Control.

Lampiran: Diagram alir Cache-Control

Diagram alir

Lampiran: Cache-Control contoh

Nilai Cache-Control Penjelasan
max-age=86400 Respons dapat di-cache oleh browser dan cache perantara hingga 1 hari (60 detik x 60 menit x 24 jam).
private, max-age=600 Respons dapat di-cache oleh browser (tetapi tidak dalam cache perantara) hingga 10 menit (60 detik x 10 menit).
public, max-age=31536000 Respons dapat disimpan oleh cache mana pun selama 1 tahun.
no-store Respons tidak diizinkan untuk disimpan dalam cache dan harus diambil sepenuhnya pada setiap permintaan.