Firebase Hosting menggunakan CDN global yang andal untuk membuat situs Anda dimuat secepat mungkin.
Setiap konten statis yang diminta secara otomatis akan disimpan dalam cache pada CDN. Jika konten situs Anda di-deploy kembali, Firebase Hosting secara otomatis akan menghapus semua konten statis yang disimpan dalam 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 berbagai hal, seperti input pengguna atau identitas pengguna. Oleh karena itu, permintaan yang ditangani oleh kode backend tidak disimpan di cache pada CDN secara default.
Namun, Anda dapat mengonfigurasi perilaku caching untuk konten dinamis. Misalnya, jika sebuah fungsi hanya menghasilkan konten baru secara berkala, Anda dapat mempercepat aplikasi dengan menyimpan konten yang dihasilkan di cache selama setidaknya periode waktu yang singkat.
Anda juga dapat mengonfigurasi perilaku caching untuk berpotensi mengurangi biaya eksekusi fungsi karena konten ditayangkan dari CDN, bukan dari fungsi yang dipicu. Baca selengkapnya tentang cara mengoptimalkan eksekusi fungsi dan layanan dalam dokumentasi Cloud Functions dan Cloud Run.
Pengecualian untuk permintaan yang menampilkan error 404. CDN meng-cache respons 404 layanan Anda ke URL yang tidak ada selama 10 menit, sehingga permintaan berikutnya untuk URL tersebut ditayangkan di luar CDN. Jika Anda mengubah layanan agar konten kini ada di URL ini, CDN akan terus menayangkan 404 yang disimpan dalam cache selama 10 menit (maksimal), kemudian menayangkan konten dari URL tersebut seperti biasa.
Jika respons 404 sudah berisi header caching yang ditetapkan oleh layanan Cloud Functions atau Cloud Run, respons tersebut akan menggantikan default 10 menit dan menentukan perilaku caching CDN sepenuhnya.
Pelajari perilaku caching lebih lanjut di dokumentasi developer web Google.
Menyetel Cache-Control
Alat utama yang Anda gunakan untuk mengelola cache konten dinamis adalah header Cache-Control. Dengan mengonfigurasi header ini, Anda dapat memberi tahu browser dan juga CDN berapa lama konten dapat disimpan dalam cache. Di fungsi Anda, setel Cache-Control seperti berikut:
res.set('Cache-Control', 'public, max-age=300, s-maxage=600');
Dalam contoh header di atas, perintah ini melakukan tiga hal:
public— Menandai cache sebagaipublic. Ini berarti baik browser dan server perantara (yaitu CDN untuk Firebase Hosting) dapat menyimpan konten dalam cache.max-age— Memberi tahu browser dan CDN berapa detik konten dapat disimpan dalam cache. Setelah waktu yang ditetapkan berakhir, browser dan CDN harus memvalidasi ulang konten dengan server asal. Dalam contoh header, kami mengizinkan browser dan CDN menyimpan konten dalam cache selama lima menit (lihats-maxagedi bawah untuk kontrol tertentu terkait caching CDN).s-maxage— Mengganti perintahmax-ageuntuk caching CDN saja; memberi tahu CDN berapa detik konten dapat disimpan dalam cache. Setelah waktu yang ditetapkan berakhir, CDN harus memvalidasi ulang konten dengan server asal. Dalam contoh header, kami mengganti setelanmax-ageuntuk CDN saja dan mengizinkan CDN menyimpan konten dalam cache selama sepuluh menit.
Untuk max-age dan s-maxage, tetapkan nilainya ke durasi terlama pengguna menerima konten usang, yang masih dapat Anda toleransi. Jika halaman berubah setiap beberapa detik, gunakan nilai waktu yang kecil. Namun, jenis konten lain dapat disimpan di cache dengan aman selama berjam-jam, berhari-hari, atau bahkan berbulan-bulan.
Anda dapat mempelajari header Cache-Control lebih lanjut di Mozilla Developer Network dan di dokumentasi developer web Google.
Kapan konten yang disimpan dalam cache ditampilkan?
Browser dan CDN menyimpan konten di cache berdasarkan:
- Hostname
- Jalur
- String kueri
- Konten header permintaan yang ditentukan di header
Vary
Header Vary
Header Vary menentukan header permintaan mana yang harus digunakan untuk memberikan respons yang sesuai (apakah konten yang disimpan dalam cache valid atau tidak, atau apakah konten harus divalidasi ulang dengan server asal).
Firebase Hosting otomatis menetapkan header Vary yang sesuai pada respons Anda untuk situasi umum. Sering kali, Anda tidak perlu mengkhawatirkan header Vary. Namun, dalam beberapa kasus penggunaan lanjutan, Anda mungkin memiliki header lain yang diperlukan untuk memengaruhi cache. Jika demikian, setel header Vary pada respons Anda. 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 setelan ini, dua permintaan identik dengan header X-My-Custom-Header berbeda akan disimpan di cache secara terpisah. Perhatikan bahwa Hosting menambahkan Cookie dan Authorization ke header Vary secara default saat ada permintaan untuk konten dinamis. Hal ini memastikan bahwa setiap header otorisasi sesi atau cookie yang Anda gunakan merupakan bagian dari kunci cache, yang mencegah kebocoran konten secara tidak sengaja.
Perhatikan juga:
Hanya permintaan
GETdanHEADyang dapat disimpan di cache. Permintaan HTTPS yang menggunakan metode lain tidak akan disimpan di cache.Hati-hati saat menambahkan setelan ke header
Vary. Semakin banyak setelan yang Anda tambahkan, semakin kecil kemungkinan CDN dapat menampilkan konten yang disimpan di cache. Ingat juga bahwaVarydidasarkan pada header permintaan, bukan header respons.
Menggunakan cookie
Saat menggunakan Firebase Hosting bersama dengan Cloud Functions atau Cloud Run, cookie umumnya dihapus dari permintaan masuk. Hal ini diperlukan agar perilaku cache CDN lebih efisien.
Hanya cookie __session dengan nama khusus yang diizinkan lolos ke eksekusi aplikasi Anda.
Jika ada, cookie __session secara otomatis dibuat menjadi bagian dari kunci cache, sehingga tidak mungkin ada dua pengguna dengan cookie yang berbeda menerima respons yang disimpan dalam cache dari pengguna satunya. Hanya gunakan cookie __session jika aplikasi Anda menayangkan konten yang berbeda sesuai dengan otorisasi pengguna.