瀏覽器快取策略全解析：Cache-Control、ETag 與 CDN 優化

HTTP 快取的兩個層次

瀏覽器請求資源
     ↓
① 強快取（不需要請求伺服器）
   Cache-Control: max-age=31536000
     ↓ 過期
② 協商快取（請求伺服器確認是否變更）
   ETag / Last-Modified → 304 Not Modified
     ↓ 資源已變更
③ 從伺服器取得新資源 → 200 OK

Cache-Control 指令詳解

指令	含義	範例情境
`max-age=N`	N 秒內直接使用快取	JS/CSS（1 年）
`s-maxage=N`	CDN 快取 N 秒	HTML（1 天）
`no-cache`	每次驗證 ETag	API 回應
`no-store`	禁止任何快取	敏感資料
`immutable`	內容永不改變	hash 檔名資源
`stale-while-revalidate=N`	過期後 N 秒內仍可用，背景更新	i18n JSON

工具庫的快取設定

# _next/static/chunks/app-abc123.js
Cache-Control: public, max-age=31536000, immutable

# /zh-TW/pdf/merge/index.html
Cache-Control: public, max-age=3600, s-maxage=86400

# /i18n/toolClients/zh-TW.json
Cache-Control: public, max-age=86400, stale-while-revalidate=604800

ETag 協商快取

# 首次請求
GET /api/config HTTP/1.1
→ 200 OK
   ETag: "abc123"
   Cache-Control: no-cache

# 再次請求
GET /api/config HTTP/1.1
   If-None-Match: "abc123"
→ 304 Not Modified（空 body，節省頻寬）

ETag 依內容 hash 產生。內容不變則回傳 304，瀏覽器使用本機快取。

CDN 快取架構

工具庫部署於阿里雲 OSS + CDN：

使用者請求 https://www.toolsku.com/zh-TW/
     ↓
CDN 邊緣節點（北京／上海／廣州）
     ↓ 快取命中 → 直接回傳（TTFB ~20ms）
     ↓ 快取未命中
OSS 源站（北京）
     ↓ 回傳資源 + 寫入 CDN 快取
CDN → 使用者

快取 Key 設計

CDN 快取 Key 通常為 URL + Query String。注意：

?v=123 與 ?v=456 是不同快取項目
帶 Accept-Language 的請求可能產生不同快取（Vary 標頭）
工具庫以 URL 路徑區分語言（/zh-CN/、/en/），避免 Vary 問題

常見快取問題

1. 更新了 JS 但使用者看到舊版

原因：舊 JS 被強快取，新 HTML 引用了新 JS 檔名但舊 JS 仍在快取中。

解法：檔名含 content hash（Next.js 預設 _next/static/chunks/app-[hash].js），內容變更則 hash 變更，自然失效。

2. HTML 快取導致內容不更新

解法：HTML 使用較短的 max-age + s-maxage，或透過 CDN 重新整理 API 主動 purge。

3. Service Worker 快取與 HTTP 快取衝突

Service Worker 的 fetch 事件可攔截所有請求，優先順序高於 HTTP 快取。更新 SW 時需遞增 cache version 並清理舊快取。

快取除錯工具

Chrome DevTools → Network：查看 Size 欄（(disk cache) / (memory cache) / 實際大小）
Response Headers：檢查 Cache-Control、ETag、Age 標頭
工具庫 HTTP 狀態碼速查：理解 200/304/404 等狀態碼含義

總結

合理的快取策略是 Web 效能的核心。強快取 + 協商快取 + CDN 邊緣節點的三層架構，讓工具庫實現 TTFB ~50ms 的極致首屏速度。理解 Cache-Control 指令與 ETag 機制，是前端效能優化的基本功。