Cache 策略應依檔案的變動頻率與體積分流
設計 cache 策略時,反直覺的一條原則:
把「易變但小量」的檔案放最弱 cache,把「不變但大量」的檔案放最強 cache。
為什麼這個分流是對的
直覺會想「全部都 cache 久一點省錢就好」,但這把可靠性押在「使用者願意等下次自然 expire」上。實際上:
- 易變但小量(
index.html,remoteEntry.js):每次 PV 回源的成本很低(KB 級),但若 cache 住會導致部署不能即時生效,需要 invalidation,而 invalidation 失敗或傳播延遲會讓 user 看到舊版 → 白屏或 chunk 404 - 不變但大量(hashed chunks):filename 含 hash,內容變了 filename 也變 → cache 永遠不會「過期但拿到錯內容」,設
immutable沒有任何風險,但能讓 99% traffic 在 edge 解決
公式
cache 強度 ∝ (檔案體積 × 請求頻率) / 變動風險
- 體積大、請求多 → 提升 cache 強度的 ROI 高
- 變動可能影響正確性 → cache 強度必須壓低
應用範例
| 檔案 | 體積 | 變動風險 | 建議 cache |
|---|---|---|---|
index.html | 小 | 高(內容換、filename 不換) | no-store |
| MFE manifest | 小 | 高 | no-store |
| Hashed JS chunks | 大 | 0(filename 變) | immutable |
| CSS/字型(hash 命名) | 中–大 | 0 | immutable |
| API JSON response | 小 | 中(依資料新鮮度) | 短 max-age + ETag |
| 使用者頭像 | 中 | 低(URL 含版本) | 中等 max-age |