Kelola perilaku cache

Firebase Hosting menggunakan CDN global yang andal untuk membuat situs Anda secepat mungkin.

Setiap konten statis yang diminta secara otomatis di-cache di CDN . Jika Anda menerapkan ulang konten situs, Firebase Hosting secara otomatis menghapus semua konten statis yang di-cache di seluruh CDN hingga permintaan berikutnya.

Namun, karena layanan Cloud Functions dan Cloud Run menghasilkan konten secara dinamis, konten untuk URL tertentu dapat bervariasi berdasarkan hal-hal seperti input pengguna atau identitas pengguna. Untuk menjelaskan hal ini, permintaan yang ditangani oleh kode backend tidak melakukan cache pada CDN secara default, dengan pengecualian permintaan yang menampilkan error 404. Untuk menghapus hasil 404 yang di-cache, terapkan ulang Firebase Hosting; men-deploy ulang Cloud Functions dan Cloud Run tidak secara otomatis membuat cache menjadi tidak valid.

Namun, Anda dapat mengonfigurasi perilaku caching untuk konten dinamis . Misalnya, jika suatu fungsi menghasilkan konten baru hanya secara berkala, Anda dapat mempercepat aplikasi dengan meng-cache konten yang dihasilkan setidaknya untuk jangka waktu singkat.

Anda juga berpotensi mengurangi biaya eksekusi fungsi karena konten disajikan dari CDN, bukan melalui fungsi yang dipicu. Baca selengkapnya tentang mengoptimalkan layanan dan eksekusi fungsi dalam dokumentasi Cloud Functions dan Cloud Run .

Pelajari lebih lanjut tentang perilaku caching di dokumentasi developer web Google .

Setel Kontrol-Cache

Alat utama yang Anda gunakan untuk mengelola cache untuk konten dinamis adalah header Cache-Control . Dengan mengonfigurasi header ini, Anda dapat mengomunikasikan ke browser dan CDN berapa lama konten Anda dapat di-cache. Dalam fungsi Anda, Anda mengatur Cache-Control seperti ini:

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

Dalam contoh tajuk ini, arahan melakukan tiga hal:

• public — Menandai cache sebagai public . Ini berarti browser dan server perantara (artinya CDN untuk Firebase Hosting) dapat meng-cache konten.

• max-age — Memberi tahu browser dan CDN berapa detik mereka dapat meng-cache konten. Saat waktu yang ditentukan habis, browser dan CDN harus memvalidasi ulang konten dengan server asal. Di header contoh, kami mengizinkan browser dan CDN untuk meng-cache konten selama lima menit (lihat s-maxage di bawah untuk kontrol khusus untuk caching CDN).

• s-maxage — Menimpa direktif max-age hanya untuk caching CDN; memberi tahu CDN berapa detik konten dapat di-cache. Ketika waktu yang ditentukan habis, CDN harus memvalidasi ulang konten dengan server asal. Di header contoh, kami mengganti setelan max-age untuk CDN saja dan mengizinkan CDN untuk meng-cache konten selama sepuluh menit.

Untuk max-age dan s-maxage , tetapkan nilainya ke jumlah waktu terlama yang Anda rasa nyaman bagi pengguna untuk menerima konten basi. Jika sebuah halaman berubah setiap beberapa detik, gunakan nilai waktu yang kecil. Namun, jenis konten lain dapat di-cache dengan aman selama berjam-jam, berhari-hari, atau bahkan berbulan-bulan.

Anda dapat mempelajari lebih lanjut tentang header Cache-Control di Jaringan Pengembang Mozilla dan di dokumentasi pengembang web Google.

Kapan konten yang di-cache disajikan?

Browser dan CDN meng-cache konten Anda berdasarkan:

• Nama host
• Jalan
• Rangkaian kueri
• Konten header permintaan yang ditentukan di header Vary

Variasikan header

Header Vary menentukan header permintaan mana yang harus digunakan untuk memberikan respons yang sesuai (apakah konten yang di-cache valid atau jika konten harus divalidasi ulang dengan server asal).

Firebase Hosting secara otomatis menyetel header Vary yang sesuai pada respons Anda untuk situasi umum. Sebagian besar waktu, Anda tidak perlu khawatir tentang header Vary . Namun, dalam beberapa kasus penggunaan tingkat lanjut, Anda mungkin memiliki header lain yang diperlukan untuk memengaruhi cache. Jika demikian, Anda dapat menyetel header Vary pada respons Anda. Sebagai contoh:

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

Dalam hal ini, nilai header Vary adalah:

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

Dengan pengaturan ini, dua permintaan identik dengan header X-My-Custom-Header berbeda di-cache secara terpisah. Perhatikan bahwa Hosting menambahkan Cookie dan Authorization ke header Vary secara default saat permintaan dibuat untuk konten dinamis. Ini memastikan bahwa header otorisasi sesi atau cookie apa pun yang Anda gunakan dijadikan bagian dari kunci cache, yang mencegah kebocoran konten yang tidak disengaja.

Juga mencatat:

• Hanya permintaan GET dan HEAD yang dapat di-cache. Permintaan HTTPS yang menggunakan metode lain tidak pernah di-cache.

• Hati-hati saat menambahkan pengaturan ke header Vary . Semakin banyak pengaturan yang Anda tambahkan, semakin kecil kemungkinan CDN dapat menyajikan konten yang di-cache. Ingat juga bahwa Vary didasarkan pada header permintaan , bukan header respons .

Menggunakan cookie

Saat menggunakan Firebase Hosting bersama dengan Cloud Functions atau Cloud Run, cookie biasanya dihapus dari permintaan yang masuk. Hal ini diperlukan untuk memungkinkan perilaku cache CDN yang efisien. Hanya cookie __session dengan nama khusus yang diizinkan untuk diteruskan ke eksekusi aplikasi Anda.

Saat ada, cookie __session secara otomatis dijadikan bagian dari kunci cache, artinya tidak mungkin bagi dua pengguna dengan cookie yang berbeda untuk menerima respons cache yang lain. Hanya gunakan cookie __session jika aplikasi Anda menyajikan konten berbeda bergantung pada otorisasi pengguna.