Firebase Hosting 使用強大的全球 CDN，盡可能提升網站速度。
系統會自動將所有要求的靜態內容快取到 CDN。如果重新部署網站內容，Firebase Hosting系統會自動清除 CDN 中所有快取內容，直到下一個要求為止。
不過，由於 Cloud Functions 和 Cloud Run 服務會動態產生內容，特定網址的內容可能會因使用者輸入內容或身分等因素而有所不同。為此，後端程式碼處理的要求預設不會在 CDN 上快取。
不過，您可以設定動態內容的快取行為。舉例來說，如果函式只會定期產生新內容，您可以快取產生的內容至少一段時間，藉此加快應用程式速度。
同樣地，您也可以設定快取行為，因為內容是從 CDN 提供，而不是從觸發的函式提供，因此可能會降低函式執行成本。如要進一步瞭解如何最佳化函式執行作業和服務，請參閱 Cloud Functions 和 Cloud Run 說明文件。
但傳回 404 錯誤的要求除外。CDN 會將服務對不存在網址的 404 回應快取 10 分鐘，因此後續對該網址的要求會由 CDN 提供服務。如果變更服務，使內容現在位於這個網址，CDN 會繼續提供任何快取的 404 錯誤訊息 (最多 10 分鐘)，然後正常提供該網址的內容。
如果 404 回應已包含由 Cloud Functions 或 Cloud Run 服務設定的快取標頭，這些標頭會覆寫預設的 10 分鐘，並完全決定 CDN 的快取行為。
如要進一步瞭解快取行為，請參閱 Google 的網頁開發人員說明文件。
設定 Cache-Control
管理動態內容快取的主要工具是 Cache-Control 標頭。設定這個標頭後，您就能向瀏覽器和 CDN 傳達內容可快取的時間長度。在函式中，您會設定 Cache-Control，如下所示：
res.set('Cache-Control', 'public, max-age=300, s-maxage=600');
在這個範例標頭中，指令會執行三項操作：
public：將回覆標示為public。也就是說，瀏覽器和中繼快取 (包括 Firebase Hosting 的 CDN) 都能快取內容。max-age：設定回應的有效時間 (以秒為單位)，超過這個時間後，系統會向原始伺服器重新驗證回應。這適用於瀏覽器；如果沒有s-maxage標頭，這項設定也適用於所有其他快取 (包括 CDN)。s-maxage：覆寫共用快取 (例如 CDN) 的max-age指令。如果 CDN 發現回應時間超過s-maxage秒，就會向原始伺服器重新驗證。在範例標頭中，瀏覽器可將回應快取 5 分鐘，但 CDN 和任何其他中繼快取可將回應快取 10 分鐘。
請將 max-age 和 s-maxage 的值設為最長的時間，讓使用者接收過時內容。如果網頁每隔幾秒就會變更，請使用較小的時間值。不過，其他類型的內容可以安全地快取數小時、數天，甚至是數月。
如要完全禁止快取 (例如一律提供最新版本的靜態內容)，您可以在 firebase.json 中使用 headers 設定進行設定：
"hosting": {
// ...
// Disables caching for the /posts route
"headers": [ {
// Change source to match your dynamically-rendered routes
"source": "/posts/**",
"headers": [ {
"key": "Cache-Control",
"value": "no-cache, no-store"
} ]
} ]
}
如要進一步瞭解 Cache-Control 標頭，請參閱 Mozilla 開發人員網路和 Google 的網頁開發人員說明文件。
系統何時會提供快取內容？
瀏覽器和 CDN 會根據下列項目快取內容：
- 主機名稱
- 路徑
- 查詢字串
Vary標頭中指定的要求標頭內容
變動標頭
Vary 標頭會決定應使用哪些要求標頭來提供適當的回應 (快取內容是否有效，或是應向原始伺服器重新驗證內容)。
Firebase Hosting會自動在常見情況下，為回應設定適當的 Vary 標頭。在大多數情況下，您不需要擔心 Vary 標頭。不過，在某些進階用途中，您可能需要影響快取，在這種情況下，您可以在回應中設定 Vary 標頭。例如：
res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');
在此情況下，Vary 標頭的值為：
vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization
使用這些設定時，系統會分別快取兩個相同的要求，但這兩個要求具有不同的 X-My-Custom-Header 標頭。請注意，要求動態內容時，Hosting 會預設將 Cookie 和 Authorization 新增至 Vary 標頭。這可確保您使用的任何工作階段或 Cookie 授權標頭都會成為快取金鑰的一部分，避免內容意外洩漏。
另請注意：
只有
GET和HEAD要求可以快取。使用其他方法傳送的 HTTPS 要求一律不會快取。將設定新增至
Vary標頭時，請務必謹慎。新增的設定越多，CDN 就越不可能提供快取內容。此外，請注意Vary是根據要求標頭，而非回應標頭。
使用 Cookie
同時使用 Firebase Hosting 和 Cloud Functions 或 Cloud Run 時，系統通常會從傳入的要求中移除 Cookie。這是為了確保 CDN 快取行為的效率。只有具備特殊名稱的 __session Cookie 可以傳遞至應用程式的執行程序。
如果存在，__session Cookie 會自動成為快取鍵的一部分，也就是說，如果兩位使用者的 Cookie 不同，就不可能收到對方的快取回應。只有在應用程式會根據使用者授權提供不同內容時，才使用 __session Cookie。