Azure帳號購買開通 Azure CDN快取時間設置多久合適

為什麼「快取時間」不是越長越好

Azure帳號購買開通 在談 Azure CDN 的快取時間（TTL）之前，先把一個常見誤區拆掉：快取時間越長，似乎就越省流量、越省回源、體驗就越快。但現實通常是「快取命中率」與「內容正確性」之間的拉扯。

CDN 的工作方式很直接：第一次請求回源取得內容，接著把內容暫存在邊緣節點，後續請求在 TTL 未過期前就不必回源。這帶來更低延遲與更少的後端壓力；但如果你的內容會頻繁變更，就會出現舊內容被持續分發的問題。

所以「合適」意味著：在大多數時間你希望命中率高、回源少，同時在內容更新時又能把錯誤的資訊控制在可接受的範圍內。換句話說，TTL 不是性能參數，而是發佈策略的一部分。

先釐清：你要快取的到底是什麼

Azure CDN 的快取規則會套用到不同類型的資源，而「內容更新節奏」往往才是決定 TTL 的核心。你可以把常見內容分成三類：

1）不常變動的靜態內容

例如圖片、CSS、JavaScript 檔案、字型檔、影片切片等。如果你採用「檔名版本化」（例如 app.8f3a1.js、logo.2026.png），那麼即便內容變了，你也會用新的檔名部署。舊檔名就可以永遠安全地快取，因為永遠不會再更新它。

2）可能會變動的靜態內容

例如首頁 banner（可能每天換）、某些不做版本化的圖片、或會被後台重新上傳的檔案。這類內容更新頻率較高，而檔名不一定變。

3）高度動態的內容

例如 API 回應、需要即時反映用戶狀態的頁面片段、或強依賴 Cookie / Authorization 的資源。這類內容快取要特別謹慎，TTL 太長會導致資料錯誤擴散到邊緣。

當你把內容類型講清楚，TTL 的選擇就變得有規律。接下來我們用更「落地」的方式討論。

TTL 的決策框架：用三個問題定範圍

你可以用以下三個問題快速收斂 TTL 範圍。

問題一：內容多久更新一次？

Azure帳號購買開通 把你最關心的那批資源列出來，例如：

• 前端靜態檔：通常每次發佈更新（可能每天/每週）
• 活動圖：每週或每日更新
• 會員相關片段：可能隨時變

如果更新頻率很高，而你仍把 TTL 設很長，就等於把「更新延遲」也一起加長。

問題二：更新時你能否做到版本化？

如果你能讓靜態檔案用版本號（content hash / build hash）命名，那 TTL 可以設得很長（甚至接近無限），更新後新檔自然會進入新的 URL，而舊檔仍可安全地留在 CDN。

如果你不能版本化，TTL 就只能短一些，或依賴手動清除快取（purge）來縮短實際可用時差。

問題三：出現舊內容，你能接受多久？

這其實是風險管理。假設一張 banner 更新後仍分發舊版本，你希望最多延遲幾分鐘？還是能接受幾小時？這個「可接受的時間窗」就是你的 TTL 候選值。

例如：

• 對「錯過活動」極其敏感：希望延遲小於 5–30 分鐘
• 對「不影響功能」的內容：可接受 1–12 小時
• 對「完全非即時」且有版本化：可接受 7 天甚至更長

Azure帳號購買開通 實務建議：常見 TTL 範圍怎麼選

下面給出一個偏實務的建議範圍。注意這不是規則，而是你可以用來起步並逐步調整的參考值。

靜態資源 + 檔名版本化：1 天到 365 天

若你的 CSS/JS/圖片都使用內容雜湊或版本號命名，建議 TTL 可以從 30 天起步，長到 180 天或 365 天也不罕見。因為「同一 URL 永不改內容」這個前提成立，TTL 越長越能放大收益。

這種情境下，性能提升通常很明顯：更高命中率、更少回源，且不會因更新而引發不一致。

靜態資源但不版本化：5 分鐘到 6 小時

若圖片或前端檔案會原地覆蓋（同一 URL 變了內容），TTL 建議短一些。

可以用這樣的方式思考：

• 更新頻繁且希望快：5–30 分鐘
• 每日或每週更新：1–6 小時
• 偶爾更新：6–24 小時

如果你真的必須把 TTL 設長以追求命中率，那就搭配更可靠的清除策略（後面會談）。

HTML / 模板頁：通常 30 秒到 5 分鐘起步

網站首頁、動態落地頁、或依賴狀態的頁面，往往不能長時間快取。即便可以做一點快取，也應該先從短 TTL 開始。

常見的做法是「短 TTL + 利用 ETag / If-None-Match」或「按條件快取」。如果你的站台在更新後能立刻清除（purge），TTL 也可以略提高。

API：以「不快取」或「極短 TTL」為原則

大多數 API 回應不應該被 CDN 隨意長快取，尤其當回應會因 Cookie、Authorization、地區、或請求參數不同而變化。

如果 API 回應是可重複的公共資料（例如公告列表、分類樹、配置檔），且你能確定快取一致性需求，那可以設置 30 秒到 5 分鐘，並配合更精準的快取鍵（例如依路徑、查詢參數、或特定 Header 決定）。

用 Cache-Control / Expires 指令把 TTL 管理變得可控

Azure帳號購買開通 Azure CDN 的快取時間，通常會與你的回應標頭（Response Headers）相互作用。最關鍵的是 Cache-Control。

max-age：指定內容在 CDN 可快取的秒數

如果你的站點對靜態檔案回應：

• Cache-Control: public, max-age=31536000

CDN 在很大程度上就能尊重這個 TTL。這也是「版本化 URL + 長 TTL」最常用的組合。

no-cache：允許快取存在但需要再驗證

Cache-Control: no-cache 的語意是「可以存，但每次請求都要向源站確認是否有更新」。這對一致性有利，但會增加回源或驗證成本。

must-revalidate：快取過期後必須回源驗證

當你希望在 TTL 到期後嚴格再驗證內容，must-revalidate 是常見選擇。若你設計得當，能在性能與一致性之間取得平衡。

如何避免標頭設錯導致「快得很爽、錯得也很快」

有些團隊會在上線早期為了性能，把所有內容統一加上很長的 max-age。問題是：一旦某些路徑其實會更新（例如活動圖、配置 JSON），你就把更新延遲也鎖死。

建議你把標頭策略拆成路徑等級或檔案類型等級，例如：

• /assets/：長 TTL
• /images/：中 TTL
• Azure帳號購買開通 /api/：短 TTL 或不快取
• /index.html：短 TTL

透過這種「分層」管理，你才有辦法同時兼顧命中率與準確性。

回源與一致性：ETag、條件式請求與清除快取

Azure帳號購買開通 TTL 是一種「時間窗」策略；一致性還需要其他工具配合。

ETag 與 304：減少回源成本的關鍵

如果你的源站支持 ETag（或 Last-Modified），CDN 在驗證時可以使用 If-None-Match 或 If-Modified-Since。當內容未更新，源站可以回覆 304，CDN 就不必重新下載完整內容。

這對「短 TTL」很有價值：你仍然保證內容更新能被迅速反映，但回源成本不會像完全重新下載那麼大。

快取清除（purge）：當你需要「超越 TTL」時

Azure帳號購買開通 有些情境下，你無法接受等待 TTL 到期。比如突發活動頁面錯誤、價格資訊需要立刻更正、或內容發布失誤要立即回滾。

此時就需要 purge（清除快取）。實務上，purge 是一個「用來縮短不一致時間」的手段，不應該用來彌補長期設錯的 TTL。

常見做法是：

• 靜態版本化資源：不太需要頻繁 purge
• 不版本化但更新頻繁的資源：需要 purge 或短 TTL
• HTML 或關鍵頁：依業務需要設定短 TTL + 必要時 purge

別忽略「部分回收」的策略成本

Purging 不是免費的。你可能會增加回源量，甚至影響短時間內的延遲。正確的做法不是「一出事就清光」，而是：建立發布流程，把清除與發佈緊密綁定。例如只針對特定路徑或特定資源類別清除。

用監控指標反推 TTL：不是憑感覺

如果你已經設定了某個 TTL，但一直不確定是否真的合適，那就用指標來驗證。

觀察回源比例與命中率

當 TTL 過短時，回源比例會上升，後端壓力增加；當 TTL 過長時，命中率提高但可能引發一致性問題。

你需要找的是平衡點：在可接受的一致性前提下，把回源壓到合理範圍。

觀察內容更新後的延遲

發佈後，關鍵頁或關鍵資源需要多久才完全更新到用戶？這個「端到端可見時間」才是對業務最有意義的指標。

如果你的平均延遲已經遠低於預期（例如你預計 30 分鐘內更新，但實際 2 分鐘就完成），你可以逐步提高 TTL 以獲得更多命中率。

觀察用戶回報與錯誤率

有些不一致不是單純「看不到最新」，而是導致功能錯誤（例如前端腳本與 API 版本不匹配）。這類問題往往需要短 TTL 或更嚴格的發佈策略（例如同時部署前端與後端版本）。

因此 TTL 的合適程度，應該和部署方式一起評估，而不是單獨看性能。

典型場景：給你可直接套用的起步方案

下面用幾個常見網站/系統的情境，提供一個「起步設定」的思路。你可以把它當作草案，再根據監控結果微調。

情境 A：電商網站，商品圖片與 JS 都版本化

假設你把前端靜態檔案與圖片都做到版本化（或內容 hash 命名），那：

• 前端靜態資源：max-age 30 天起步，可到 180 天
• 部分不版本化的活動圖：1–6 小時
• 首頁 HTML：30 秒到 3 分鐘
• API：短快取或不快取（依是否有公共資料）

並把 purge 用在活動圖與 HTML 的回滾。

情境 B：部落格/媒體網站，內容每天更新但相對穩定

例如每篇文章是靜態頁，更新頻率不高：

• 文章內部圖片、CSS、JS：版本化則長 TTL；否則 12 小時到 3 天
• 文章 HTML：短 TTL（5 分鐘到 1 小時），或利用 ETag 驗證
• 首頁：5 分鐘起步
• 搜尋/個人化：避免長快取

目標是讓新文章或修改內容能在合理時間內被看見，同時保持命中率。

情境 C：SaaS 後台，強依賴登入狀態

這類系統通常不要讓 CDN 在不安全的前提下快取敏感內容：

• 靜態資源（JS/CSS/圖）：長 TTL（前提是版本化）
• HTML：短 TTL 或不快取（依架構）
• API：極短 TTL 或直接關閉快取；若要快取必須做嚴格的快取鍵與授權隔離

同時確保 CDN 與後端的版本策略一致，避免前端讀到舊 API 行為。

常見踩雷點：讓 TTL 設置失效的原因

1）忘記檔名版本化，卻把 max-age 設太長

這是最常見的錯誤。結果就是同一 URL 永遠命中舊內容，用戶永遠等不到更新。

2）快取鍵沒考慮查詢參數或 Header

如果同一路徑在不同查詢參數或 Header 下返回不同內容，但你卻把它們都視為同一個快取條目，就會引發「跨用戶/跨條件」的錯誤回應。

3）把 HTML 與 API 一起套用同樣 TTL

HTML 往往需要快速反映，API 可能更敏感。把 TTL 一刀切通常只會在某一段時間造成不必要的風險。

4）只看命中率，不看一致性回饋

你可能發現命中率提升了，但用戶端的投訴開始上升（例如活動資訊不對、頁面顯示延遲）。沒有一致性指標，就容易把快取當成純性能最佳化。

結論：合適 TTL 的核心是「可控的更新延遲」

回答標題「Azure CDN 快取時間設置多久合適」的真正意思，是：在你能接受的更新延遲範圍內，取得足夠的命中率與成本效益。

若你把靜態資源做到版本化，TTL 可以設定得很長（甚至數月以上），因為 URL 不再改內容，風險被你在架構層面消掉了。若內容會原地覆蓋，那 TTL 就必須短一些，並配合 purge 或 ETag 驗證來保障一致性。對高度動態的內容，則要保守，避免讓錯誤資訊在邊緣擴散。

最後，把 TTL 當成一套「發佈與回滾流程」的一部分來設計。你會發現：當 TTL 與版本策略、監控指標和清除機制對齊時，CDN 的快就是快、內容的一致性也會穩。

Azure帳號購買開通 附錄：一個簡單的 TTL 起步表（可自行替換為你的路徑規則）

資源類型	建議 TTL 起步	適用前提
版本化靜態檔（JS/CSS/字型/圖片）	30–180 天（可更長）	同 URL 不改內容
不版本化但更新頻繁的圖片/檔案	5 分鐘–6 小時	允許短延遲或可 purge
HTML（首頁/落地頁）	30 秒–5 分鐘	需要快速反映更新
API（公共且可快取者）	30 秒–5 分鐘或關閉	快取鍵正確、授權隔離

當你用監控驗證後，再把 TTL 在「可接受的一致性時間窗」內逐步調整，你就會得到真正屬於你系統的合適答案。