CDN 優化實戰指南 2026：快取策略、壓縮設定與效能調校

Q: 裝了 CDN，速度卻沒變快，怎麼查？

先確認 CDN 真的生效（DevTools 看回應標頭），再看快取命中率。命中率低就依「常見設定錯誤」逐項排查：Cache-Control 設太保守、query string 破壞快取、沒開壓縮是三大主因。若命中率已高但仍慢，問題多半在源站本身。

2/3/202617 min 分鐘閱讀

#CDN#快取策略#效能優化#Brotli#HTTP/3#邊緣運算#快取命中率

CDN 優化實戰指南：快取策略、壓縮設定與效能調校

CDN 優化實戰指南【2026】

CDN 裝上去只是第一步。真正決定網站快不快的，是後面的快取策略、壓縮、傳輸協定與邊緣設定——同一家 CDN，調得好跟調不好，載入速度可以差好幾倍。

這篇談的是**「怎麼把 CDN 調到最快」**，不談選哪一家、也不算費用。如果你還在選型或想比帳單，先看下面兩篇：

選哪家、節點與功能怎麼比 → CDN 廠商完整比較
各家怎麼計費、怎麼省錢 → CDN 費用完整指南
想要一步步照做的設定清單 → CDN 設定優化教學

本篇則聚焦「原理與調校決策」：每個優化槓桿為什麼有效、怎麼判斷該不該用、以及設定錯了會怎樣。

優化前：先量出你的基準

優化最常見的錯誤，是還沒量測就開始亂調。先建立基準，之後每一項改動才知道有沒有效。

三個一定要先看的指標：

快取命中率（Cache Hit Ratio）：邊緣節點直接命中、不必回源的比例。這是 CDN 優化的總分。
TTFB（Time to First Byte）：從發出請求到收到第一個位元組的時間，反映邊緣與回源的反應速度。
LCP（Largest Contentful Paint）：最大內容繪製時間，是 Google Core Web Vitals 的核心指標，直接關係使用者感受與搜尋排名。

量測工具可用 PageSpeed Insights、WebPageTest、GTmetrix，並搭配 CDN 後台的 Analytics 看命中率。記下優化前的數字，後面每動一項就重測一次。

一、快取策略：命中率是一切的根本

快取命中率越高，回源越少，速度越快、費用也越低。策略核心是「用 Cache-Control 告訴 CDN 每種資源該快取多久」。

分層設定 Cache-Control

不同類型的資源，快取策略天差地遠：

# 靜態資源（含 hash 檔名）：長期快取 + immutable
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2|webp|avif)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

# HTML：短期快取或不快取（內容常變）
location ~* \.html$ {
    add_header Cache-Control "no-cache, must-revalidate";
}

# API：通常不快取
location /api/ {
    add_header Cache-Control "no-store";
}

幾個關鍵指令的意義：

max-age：資源可被快取的秒數（31536000 = 一年）。
immutable：告訴瀏覽器這個檔案在有效期內不會變，連「重新驗證」都省了——搭配 build 時產生 hash 檔名（如 app.9f3c.js）最有效。
public：允許共享快取（CDN、代理）保存。
s-maxage：專門給 CDN／共享快取用的存活時間，可與瀏覽器的 max-age 分開設定，讓邊緣多快取、瀏覽器少快取。

提高快取命中率的實務

命中率上不去，通常是這幾個原因：

Query string 破壞快取：許多 CDN 預設把帶不同 query string 的 URL 視為不同資源。追蹤參數（?utm_source=…）會讓同一張圖被當成無數份，命中率崩掉。設定 CDN 忽略非必要的 query string。
Vary 標頭用過頭：Vary: User-Agent 之類會為每種瀏覽器各存一份快取，命中率大幅下降。只在真正需要內容協商時使用（如 Vary: Accept-Encoding）。
HTML 完全不快取：登出狀態的頁面其實可以快取，用 cookie 區分登入／登出流量，讓匿名訪客也吃到邊緣快取。

清快取（Purge）策略

內容更新時要讓舊快取失效，但頻繁全站清快取既慢又可能產生費用（例如 CloudFront 前 1,000 次/月免費、之後每次計費）。更好的做法：

版本化檔名：改檔案就換名（style.v2.css），根本不必清快取。
精準清除：只清有變動的路徑，不要動不動 purge 整站。
Soft Purge：支援的 CDN（如 Fastly）可先標記為 stale、背景重抓，避免瞬間全部回源打爆源站。

二、壓縮：Brotli 與 gzip

壓縮是投報率最高的優化——設定一次，之後每個文字資源都變小。

gzip：相容性最好，幾乎所有瀏覽器都支援，是安全底線。
Brotli：Google 開發的較新演算法，對 HTML/CSS/JS 這類文字內容壓縮更好。依 Cloudflare 官方文件，Brotli 對文字內容約比 gzip 再小 20%（實際依內容而定）。

以 Cloudflare 為例，各方案的預設壓縮不同：Free 方案預設 Zstandard、Pro/Business 預設 Brotli、Enterprise 預設 gzip（來源見文末）。

注意事項：

只壓縮文字類資源。JPEG、PNG、WebP、AVIF、影片、.zip 這類本來就已壓縮的檔案，再壓縮幾乎沒效果，只是白費 CPU。
Cache-Control: no-transform：若源站回應帶這個標頭，會要求 CDN 不要更動壓縮方式。需要 CDN 幫你重新壓縮時，源站別誤送這個標頭；反之想保留源站自己的壓縮結果時才加。這個指令只能由源站設定，用戶端請求無法加上。

三、圖片優化

圖片通常是頁面裡最重、最值得優化的部分。

選對格式

格式	特性	建議使用場景
WebP	主流瀏覽器已全面支援，同品質下明顯小於 JPEG	通用首選
AVIF	壓縮率更高，現代瀏覽器普遍支援	新專案、追求最小體積
JPEG	相容性 100%	舊環境相容備援
PNG	無損、支援透明	需要透明度或銳利邊緣

用 <picture> 讓瀏覽器自己挑最好的格式，並保留 JPEG 作為備援：

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="描述" loading="lazy">
</picture>

其他重點：

loading="lazy"：讓首屏以外的圖片延後載入，改善 LCP。
響應式圖片：用 srcset 提供多種尺寸，手機不必下載桌機大圖。
CDN 內建的圖片優化：多數 CDN 提供即時轉檔／縮放（如 Cloudflare Images、Polish），可把原圖自動轉成 WebP/AVIF 並依裝置調整尺寸，省去自己維護多份檔案。具體功能與計費以各家官方頁為準。

四、HTTP/3 與 QUIC

HTTP/3 建立在 QUIC 協定（基於 UDP）之上，相對於 HTTP/2 的改善：

更快的連線建立：支援 0-RTT，回訪連線幾乎免握手延遲。
消除 head-of-line blocking：單一封包遺失不會卡住其他串流，對高遺失率網路特別有感。
連線遷移：手機從 Wi-Fi 切到行動網路時連線不中斷，行動體驗更順。

主流 CDN 大多已支援 HTTP/3（例如 Cloudflare 各方案，含 Free，皆含 HTTP/2 與 HTTP/3＋QUIC）。確認在 CDN 後台把它打開——很多站點其實沒啟用，白白錯過。

五、預載與資源提示

除了 CDN 本身，善用瀏覽器的資源提示（Resource Hints）能進一步縮短關鍵資源的取得時間：

preconnect：提前對關鍵網域（如你的 CDN 網域）完成 DNS、TCP、TLS 握手，等真正要抓資源時省下往返。
```
<link rel="preconnect" href="https://cdn.example.com" crossorigin>
```
dns-prefetch：只做 DNS 預先解析，比 preconnect 輕量，適合次要的第三方網域。
preload：宣告「這個資源等一下一定會用到，請優先抓」，常用於首屏字型、關鍵 CSS、LCP 圖片。
```
<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>
```
Early Hints（103）：部分 CDN 支援在源站還在處理時，先送 103 Early Hints 讓瀏覽器提早開始 preconnect／preload，進一步壓低等待時間。是否支援與如何啟用，以各 CDN 官方文件為準。

原則：只 preload 真正關鍵的少數資源。什麼都 preload 會互相搶頻寬，反而拖慢首屏。

六、邊緣運算與邊緣函式

邊緣運算讓你把程式碼直接跑在 CDN 節點上，靠近使用者、不必每次都回源，用來降低延遲與源站負載。

常見用途：

地理位置重導向：依國家／地區在邊緣直接導向對應版本。
A/B 測試：在邊緣分流，避免回源判斷造成的延遲。
認證與授權：在邊緣驗 token、擋掉未授權請求，不讓流量打到源站。
動態內容組裝：在邊緣拼裝個人化片段，兼顧快取與客製。

各家的邊緣運算平台：

Cloudflare Workers：主打近乎零冷啟動的通用邊緣運算。
AWS Lambda@Edge：與 AWS 深度整合，適合已在 AWS 生態的架構。
CloudFront Functions：輕量、專為 header 改寫等短任務設計。
Fastly Compute（前身 Compute@Edge）：以 WebAssembly 執行邊緣程式碼。

各平台的執行模型、冷啟動表現與計費差異很大，選用前請對照官方文件；本篇不列具體數字以免過時。

七、常見設定錯誤

「裝了 CDN 卻沒變快」，九成是設定問題。優先排查這幾項：

CDN 其實沒生效：用瀏覽器 DevTools → Network 看回應標頭有沒有 cf-cache-status、x-cache 之類。沒有，代表請求根本沒走 CDN。
快取命中率過低：多半是 Cache-Control 設成 no-cache／no-store、query string 破壞快取、或 Page Rules／快取規則設錯，導致大多數請求還是回源。
沒開壓縮：忘了啟用 Brotli／gzip，文字資源以原始大小傳輸，白白多花頻寬與時間。
HTML 一律不快取：把所有頁面都設 no-store，等於放棄邊緣快取；匿名頁面其實可以快取。
Vary 或 query string 造成快取碎片化：同一份內容被拆成無數快取版本，命中率再怎麼調都上不去。
Price Class／節點範圍設錯：用戶其實都在亞洲，卻用了含南美、非洲的全球節點範圍，既沒更快又更貴。
源站本身慢：CDN 只加速「可快取」的部分，第一次回源與動態內容仍取決於源站。快取命中率已高但還是慢，就要回頭優化源站。

八、監控與持續調校

優化不是一次性的。上線後持續盯這幾個指標，異常就回頭查：

指標	經驗參考值	警告門檻
快取命中率	>90%	<80%
回源延遲	<200ms	>500ms
錯誤率	<0.1%	>1%
TTFB	<100ms	>300ms

上表為一般網站的經驗參考值，實際目標依內容類型（靜態為主可更高、電商動態多可略低）與業務需求調整。

搭配 CDN 後台的 Analytics 與告警（Billing Alerts、流量／錯誤率告警），讓問題在使用者發現前就被抓到。

常見問題 FAQ

裝了 CDN，速度卻沒變快，怎麼查？

先確認 CDN 真的生效（DevTools 看回應標頭），再看快取命中率。命中率低就依「常見設定錯誤」逐項排查：Cache-Control 設太保守、query string 破壞快取、沒開壓縮是三大主因。若命中率已高但仍慢，問題多半在源站本身。

快取命中率多少算健康？怎麼提高？

以靜態內容為主的網站，命中率 90% 以上算健康；一般網站 80% 以上、電商 70% 以上可接受。提高的做法：靜態資源設長 max-age＋immutable、忽略非必要 query string、少用 Vary、匿名 HTML 也開快取。

動態內容或會員頁能用 CDN 加速嗎？

可以，只是策略不同。動態頁本身多半不快取，但可以：靜態資源（圖片、CSS、JS）照樣邊緣快取；用邊緣運算在節點處理認證、重導向；登出狀態的頁面用 cookie 區分後快取。搭配 HTTP/3 與壓縮，動態站也能明顯變快。

CDN 對 SEO 有幫助嗎？

有，主要透過「速度」這個排名因素。CDN 改善 LCP、TTFB 等 Core Web Vitals，而網站速度是 Google 明確的排名訊號。但 CDN 只是其中一個因子——內容品質與連結同樣重要，速度快救不了內容差。

CDN 已經上線，但不確定有沒有調到最好？

CloudInsight 提供：

快取策略檢視與命中率調校
壓縮、HTTP/3、圖片與預載優化
邊緣運算應用設計
效能監控與持續優化

預約免費諮詢，讓我們幫你把現有 CDN 的效能榨到最盡。

參考資源

需要專業的雲端建議？

無論您正在評估雲平台、優化現有架構，或尋找節費方案，我們都能提供協助

預約免費諮詢

AWS Lambda