Firebase 託管使用強大的全球 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 Developer Network和 Google 的Web 開發人員文檔中了解有關Cache-Control
標頭的更多信息。
什麼時候提供緩存內容?
瀏覽器和 CDN 緩存您的內容基於:
- 主機名
- 路徑
- 查詢字符串
Vary
header中指定的請求頭的內容
改變標題
Vary
標頭確定應該使用哪些請求標頭來提供適當的響應(緩存的內容是否有效,或者內容是否應該通過源服務器重新驗證)。
對於常見情況,Firebase 託管會自動在您的響應中設置適當的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 託管與 Cloud Functions 或 Cloud Run 一起使用時,cookie 通常會從傳入請求中刪除。這是實現高效 CDN緩存行為所必需的。僅允許特別命名的__session
cookie 傳遞給您的應用程序執行。
如果存在, __session
cookie 會自動成為緩存鍵的一部分,這意味著具有不同 cookie 的兩個用戶不可能接收到對方的緩存響應。如果您的應用程序根據用戶授權提供不同的內容,則僅使用__session
cookie。