Firebase Hosting 使用強大的全球 CDN 使您的網站盡可能快。
任何請求的靜態內容都會自動緩存在 CDN 上。如果您重新部署網站的內容,Firebase 託管會自動清除 CDN 上所有緩存的靜態內容,直到下一個請求為止。
但是,由於 Cloud Functions 和 Cloud Run 服務動態生成內容,因此給定 URL 的內容可能會根據用戶輸入或用戶身份等因素而有所不同。考慮到這一點,默認情況下,後端代碼處理的請求不會在 CDN 上緩存,返回 404 錯誤的請求除外。要清除緩存的 404 結果,請重新部署 Firebase 託管;重新部署 Cloud Functions 和 Cloud Run不會自動使緩存失效。
不過,您可以配置動態內容的緩存行為。例如,如果某個函數僅定期生成新內容,您可以通過將生成的內容緩存至少一小段時間來加快應用程序的速度。
您還可以潛在地降低函數執行成本,因為內容是從 CDN 提供的,而不是通過觸發函數提供的。在Cloud Functions和Cloud Run文檔中了解有關優化函數執行和服務的更多信息。
在 Google 的網絡開發人員文檔中了解有關緩存行為的更多信息。
設置緩存控制
用於管理動態內容緩存的主要工具是Cache-Control
標頭。通過配置此標頭,您可以與瀏覽器和 CDN 溝通您的內容可以緩存多長時間。在您的函數中,您可以像這樣設置Cache-Control
:
res.set('Cache-Control', 'public, max-age=300, s-maxage=600');
在此示例標頭中,指令執行三件事:
public
— 將緩存標記為public
。這意味著瀏覽器和中間服務器(即 Firebase 託管的 CDN)都可以緩存內容。max-age
— 告訴瀏覽器和 CDN 他們可以緩存內容多少秒。當設定的時間到期時,瀏覽器和 CDN 必須與源服務器重新驗證內容。在示例標頭中,我們允許瀏覽器和 CDN 將內容緩存五分鐘(有關 CDN 緩存的特定控制,請參閱下面的s-maxage
)。s-maxage
— 僅覆蓋 CDN 緩存的max-age
指令;告訴 CDN 它可以緩存內容多少秒。當設定的時間到期時,CDN 必須與源服務器重新驗證內容。在示例標頭中,我們僅覆蓋 CDN 的max-age
設置,並允許 CDN 將內容緩存十分鐘。
對於max-age
和s-maxage
,將其值設置為您願意讓用戶接收過時內容的最長時間。如果頁面每隔幾秒更改一次,請使用較小的時間值。然而,其他類型的內容可以安全地緩存數小時、數天甚至數月。
您可以在Mozilla 開發人員網絡和 Google 的Web 開發人員文檔中了解有關Cache-Control
標頭的更多信息。
何時提供緩存內容?
瀏覽器和 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。