入口檔與 hashed chunks 兩極化 cache 策略
部署產物分兩類,cache 策略完全相反才能同時拿到「即時生效」與「省 bandwidth」。
| 檔案類型 | Cache-Control | 理由 |
|---|---|---|
index.html, remoteEntry.js | no-cache, no-store, max-age=0, must-revalidate | filename 不變、內容會被覆蓋 → 必須每次回源 |
Hashed chunks(main.abc123.js) | public, max-age=31536000, immutable | filename 含 hash,內容變 filename 也變 → 永遠可 cache |
Header 為什麼寫這麼多
no-cache, no-store, max-age=0, must-revalidate 看似冗餘,實為對抗各種行為不一致的 cache 層:
no-store:任何 cache 都不准存no-cache:即使存了也必須先 revalidatemax-age=0:存活時間為 0must-revalidate:過期後不准用 stale
多寫幾個 directive 是兼容「某些舊 proxy 只認其中一個」。
Immutable 的威力
hashed chunks 加 immutable 後,user 重新整理頁面時瀏覽器完全不發 conditional request(連 304 都省) → 省 latency 的關鍵(GCP 上不省 egress,見 GCP immutable 主要省 GCS 請求與 latency 而非 egress)。
設計哲學
把「易變但小量」的檔案放最弱 cache,把「不變但大量」的檔案放最強 cache。 成本花在刀口上,可靠性保留在關鍵路徑。
入口檔不 cache 的「保險費」在 10 萬 PV/天規模 < $11/月,換到部署即時生效、不需要 invalidation、sweep 安全執行。