使用內容傳遞網路改善效能。
內容傳遞網路 (CDN) 使用分散式伺服器網路向使用者供應資源，藉此提升網站效能。CDN 可減少伺服器負載，因此能降低伺服器費用，非常適合處理尖峰流量。本文會討論 CDN 的運作方式，並提供各平台通用的指引，讓您選擇、設定及最佳化 CDN 設定。
總覽
內容傳遞網路由經過最佳化處理的伺服器伺服器組成，可快速將內容傳遞給使用者。雖然 CDNs 絕對以提供快取內容聞名，但 CDN 也有助於改善無法快取的內容傳遞。一般來說，透過 CDN 傳遞的網站越多越好。
大致上來說，CDN 的效能優勢源自於少數幾個原則：CDN 伺服器與原始伺服器相較，因此往返時間 (RTT) 更短；透過網路最佳化，CDN 可以比「直接」從來源伺服器載入內容，更快傳遞內容；最後，再者，不再需要透過來源 CDN 快取傳遞內容。
資源提供
雖然這看似不合直覺，但使用 CDN 傳遞資源 (即使是無法快取的資源) 通常比將使用者「直接從伺服器載入」的速度更快。
使用 CDN 傳遞資源時，系統會在用戶端與附近的 CDN 伺服器之間建立新連線。歷程的其餘部分 (也就是 CDN 伺服器和來源之間的資料移轉作業) 會透過 CDN 的網路進行，其中通常包含與來源的現有持續連線。這麼做的優點有兩個優點：請盡可能終止離使用者的新連線，以免除不必要的連線設定費用 (建立新連線費用高昂，需要多次往返)。使用預先暖機連線，即可在可能的處理量上限的情況下立即傳輸資料。
有些 CDN 甚至可以透過遍及網際網路的多個 CDN 伺服器，將流量轉送至來源，進一步改善這一點。CDN 伺服器之間的連線是透過可靠且最佳化調整的路徑發生，而不是由邊界閘道通訊協定 (BGP) 決定的路徑。雖然 BGP 是網際網路的基本轉送通訊協定，但轉送決策不一定是以效能為導向。因此，BGP 決定的路徑可能比 CDN 伺服器之間經過微調的路徑效能低落。
快取
在 CDN 伺服器上快取資源後，就不需要為了提供服務而請求傳送至來源。因此，可加快資源提供速度，同時降低原始伺服器的負載。
將資源新增至快取
填入 CDN 快取最常見的方法，是讓 CDN 在需要時「提取」資源，這稱為「來源提取」。第一次向快取要求特定資源時，CDN 會從原始伺服器要求該資源並快取回應。透過這種方式，系統就會隨著時間累積額外的未快取資源，而透過此方式建立快取內容。
從快取中移除資源
CDN 會使用快取清除功能，定期從快取中移除不實用的資源。此外，網站擁有者也可以使用清除功能明確移除資源。
移除快取
快取具有有限的儲存空間容量。當快取接近容量上限時，系統會移除最近未存取或占用大量空間的資源，藉此釋出空間給新資源。這項程序稱為快取移除。從一個快取中移除的資源，不代表已經從 CDN 網路中的所有快取中移除了資源。
清除
清除 (也稱為「快取撤銷」) 是一種從 CDN 快取中移除資源的機制，不必等待資源過期或撤銷。一般是透過 API 執行。在需要撤銷內容的情況下 (例如修正錯字、價格錯誤或新聞報導不正確) 時，保留非常重要。除此之外，雲端技術也在網站的快取策略中扮演重要角色。
如果 CDN 支援近乎即時的清除，可使用清除功能來當做管理動態內容快取的機制：使用較長的存留時間快取動態內容，然後在資源更新時清除資源。透過這種方式，即使無法事先得知資源何時會變更，也可以大幅縮短動態資源的快取持續時間。這項技術有時稱為「待定的快取」。
大規模使用清除時，通常會搭配「快取標記」或「代理快取金鑰」的概念使用。這項機制可讓網站擁有者將一或多個額外的 ID (有時稱為「標記」) 與快取資源建立關聯。接著，這些標記就能用於執行高度精細的清除作業。舉例來說，您可以為包含網站頁尾的所有資源 (例如
/about、/blog) 新增「footer」標記。更新頁尾後，請指示 CDN 清除與「footer」代碼相關聯的所有資源。
可快取的資源
資源的快取方式和方法取決於其為公開或私人；靜態或動態。
私人和公開資源
私人資源
私人資源包含適用於單一使用者的資料，因此不應由 CDN 快取。私人資源會以
Cache-Control: private標頭表示。公開資源
公開資源不包含使用者專屬資訊，因此可由 CDN 快取。如果資源沒有
Cache-Control: no-store或Cache-Control: private標頭，則 CDN 可能會視為可快取的資源。可快取公開資源的時間長度，取決於資產變更的頻率。
動態和靜態內容
動態內容
動態內容是指會經常變更的內容。API 回應和商店首頁都屬於這類內容。然而，這種內容經常變更，並不一定代表該內容就會快取結果。在流量較大的期間，在極短的時間內 (例如 5 秒) 快取這些回應，可以大幅降低原始伺服器的負載，同時將對資料更新間隔的影響降到最低。
靜態內容
靜態內容不會經常變更 (如果有的話)。圖片、影片和版本化資料庫通常就是這類內容類型的例子。由於靜態內容不會變更，因此應設定長時間的存留時間 (TTL)，例如 6 個月或 1 年。
選擇 CDN
選擇 CDN 時，效能通常是首要考量。不過，在選擇 CDN 時，CDN 提供的其他功能 (例如安全性與數據分析功能) 以及 CDN 的定價、支援和新手上路等，都是很重要的一點。
效能
整體來說，CDN 的效能策略可以考慮，在盡可能降低延遲時間與盡量提高快取命中率之間進行取捨。具有多個服務點 (PoP) 的 CDN 可以縮短延遲時間，但由於流量會分配到更多的快取中，所以快取命中率可能會較低。反之，PoP 較少的 CDN 可能位於較遠的地理位置，但可在快取命中率較高的位置。
因此，基於這種取捨，部分 CDN 會採用分層式快取方法，也就是位於使用者附近的 PoP (也稱為「邊緣快取」) 會補上快取命中率較高的中央 PoP。當邊緣快取找不到資源時，系統會尋找資源的中央 PoP。這種方法的延遲時間稍微較長，就更有可能可從 CDN 快取提供資源，但不一定是邊緣快取。
盡可能減少延遲時間與盡量提高快取命中率之間的平衡點。畢竟，並沒有特定做法。不過，視自家網站的性質及其使用者族群而定，您可能會發現其中一種方法的成效明顯優於另一種方法。
另外值得注意的是，CDN 的效能可能會因地理位置、時段，甚至是時事而有顯著差異。雖然您一定是在為 CDN 的效能進行研究，但很難預測 CDN 能提供的確切成效。
對最大內容繪製 (LCP) 的影響
如前文所述，CDN 的主要目的是透過將資源分配給距離使用者較近的伺服器，進而減少延遲時間。因此，CDN 的主要優點在於能改善載入效能。特別是，將 CDN 導入您網站的伺服器端架構時，資源的第一個位元組時間 (TTFB) 就能大幅改善。
雖然 TTFB 不是以使用者為中心的成效指標，但對於診斷最大內容繪製 (LCP) 的問題，TTFB 是一項以使用者為中心的指標，因此是診斷問題的重要指標。
CDN 特別能有效改善 LCP，因為這麼做不僅可減少連線設定和快取文件的 TTFB，還能改善轉譯 LCP 元素所需的任何靜態資源傳送作業。
其他功能
除了核心 CDN 服務外，CDN 通常還提供多項功能。常見的功能包括：負載平衡、圖片最佳化、影片串流、邊緣運算和安全性產品。
如何設定及設定 CDN
在理想情況下，您應該使用 CDN 為整個網站提供服務。整體而言，這項程序的設定程序包括向 CDN 供應商註冊，接著更新 CNAME DNS 記錄，使其指向 CDN 供應商。舉例來說，www.example.com 的 CNAME 記錄可能指向 example.my-cdn.com。隨著 DNS 變更，流量會經由 CDN 轉送。
如果無法使用 CDN 提供所有資源，您可以將 CDN 設定為只提供靜態資源子集，例如。您可以另外建立 CNAME 記錄，專門用於應由 CDN 提供的資源。舉例來說，您可以建立指向 example.my-cdn.com 的 static.example.com CNAME 記錄。此外，您還必須重新編寫由 CDN 提供的資源網址，使其指向您建立的 static.example.com 子網域。
雖然您的 CDN 會在此時設定完成，但設定可能會效率低下。接下來的兩節將說明如何透過提高快取命中率及啟用效能功能，發揮 CDN 的最大效益。
提高快取命中率
有效的 CDN 設定會從快取盡可能提供最多資源。這通常是以快取命中率 (CHR) 計算。快取命中率是指在特定時間間隔內，快取命中數除以要求總數所得的值。
新初始化的快取的 CHR 為 0，但隨著填入資源，此情況也會增加。CHR 為 90% 是大多數網站良好的目標。您的 CDN 供應商應為您提供 CHR 的相關分析和報告。
最佳化 CHR 時，首先要確認所有可快取資源都有快取和快取時間是否正確。這是一項簡單的評估，應由所有網站進行。
大致來說，接下來的 CHR 最佳化做法是微調 CDN 設定，確保系統不會個別快取具邏輯性的伺服器回應。這是一種效率低落的現象，是因為查詢參數、Cookie 和快取要求標頭等因素所產生影響。
初步稽核
大多數 CDN 會提供快取分析，此外，你也能使用 WebPageTest 和 Lighthouse 等工具，快速確認網頁的所有靜態資源處理時間是否正確。方法是檢查每個資源的 HTTP 快取標頭。使用最長的存留時間 (TTL) 快取資源，可避免日後進行不必要的來源擷取，從而增加 CHR。
通常， CDN 必須設定下列標頭中的其中一個：
Cache-Control: max-age=Cache-Control: s-maxage=Expires
此外，雖然這不會影響 CDN 對資源進行快取的方式或如何進行快取，但我們建議您一併設定 Cache-Control: immutable 指令。Cache-Control: immutable 表示資源「在更新生命週期期間不會更新」。因此，透過瀏覽器快取提供資源時，瀏覽器不會重新驗證，進而消除不必要的伺服器要求。很抱歉，只有 Firefox 和 Safari 支援這個指令，因為 Chromium 瀏覽器不支援這項指令。這個問題會追蹤 Chromium 支援 Cache-Control: immutable 的情形。為這個問題加上星號有助於鼓勵我們支援這項功能。
如需有關 HTTP 快取的詳細說明，請參閱「使用 HTTP 快取避免不必要的網路要求」。
微調
簡單說明 CDN 快取的運作方式：使用資源的網址做為快取及擷取快取資源的金鑰。在實務上，這個情況仍然並不常見，但由於要求標頭和查詢參數所造成的影響，會稍微複雜。因此，重寫要求網址是提升 CHR 和確保為使用者提供正確內容的重要技術。正確設定的 CDN 執行個體能在過度精細的快取 (這會影響 CHR) 和精細快取之間 (導致向使用者提供錯誤回應) 之間取得適當平衡。
查詢參數
根據預設，CDN 會在快取資源時將查詢參數納入考量。但是，對查詢參數處理微幅調整可能會對 CHR 造成重大影響。例如：
不必要的查詢參數
根據預設，即使
example.com/blog和example.com/blog?referral_id=2zjk可能為相同的基礎資源，CDN 會分別快取example.com/blog和example.com/blog?referral_id=2zjk。如要解決這個問題，請調整 CDN 的設定，使其忽略referral\_id查詢參數。查詢參數順序
CDN 會和
example.com/blog?query=dogs&id=123分開快取example.com/blog?id=123&query=dogs。對大多數網站來說，查詢參數順序並不重要，因此設定 CDN 為查詢參數排序 (藉此將用來快取伺服器回應的網址正規化)，CHR 就會增加。
變化
Vary 回應標頭會告知快取，伺服器回應的特定網址會因要求中的標頭而異 (例如 Accept-Language 或 Accept-Encoding 要求標頭)。因此，它會指示 CDN 分別快取這些回應。CDN 並未廣泛支援 Vary 標頭，因此可能無法從快取提供可快取的資源。
雖然 Vary 標頭可能是實用工具，但不當使用會對 CHR 造成不良影響。此外，若您使用 Vary，將要求標頭正規化將有助於改善 CHR。舉例來說，如果沒有將要求標頭 Accept-Language: en-US 和 Accept-Language: en-US,en;q=0.9 正規化，則即使要求標頭的內容可能相同，也會產生兩個不同的快取項目。
餅乾
Cookie 是透過 Cookie 標頭在要求上設定，而 Cookie 是在回應上透過 Set-Cookie 標頭設定。一般而言，快取不會快取包含此標頭的伺服器回應，因此請勿不必要的 Set-Cookie 標頭。
效能功能
本節說明 CDNs 在其核心產品中提供的效能功能。許多網站都忘了啟用這些功能，因而錯失了輕鬆提升成效的機會。
壓縮
所有以文字為基礎的回應都必須使用 gzip 或 Brotli 壓縮。如果可以，請選擇「Brotli」，使用 Gzip。Brotli 是新版的壓縮演算法，相較於 gzip，這個演算法的壓縮率較高。
Brotli 壓縮的 CDN 支援兩種類型：「Brotli from origin」和「自動 Brotli 壓縮」。
Brotli 出品
Brotli 的來源是 CDN 提供的資源是由來源經過 Brotli 壓縮。雖然這看起來像是所有 CDN 都應立即支援的功能，但 CDN 必須能夠快取與指定網址相對應的資源的多個版本 (也就是 gzip 壓縮和 Brotli 壓縮版本)。
自動 Brotli 壓縮
自動 Brotli 壓縮是指 SDK 壓縮了 Brotli 的資源。CDN 能夠壓縮可快取及不可快取的資源。
第一次要求資源時，會以「良好」的壓縮方式提供，例如 Brotli-5。這類壓縮適用於可快取及不可快取的資源。
另一方面，如果資源可供快取，CDN 就會使用離線處理功能，以功能更強大、但壓縮程度更低的壓縮程度壓縮資源，例如 Brotli-11。壓縮完成後，系統會快取更多的壓縮版本，以供後續要求使用。
壓縮最佳做法
如果想要盡可能提高效能，應同時在原始伺服器和 CDN 中套用 Brotli 壓縮。來源的 Brotli 壓縮會將快取無法提供的資源傳輸大小降到最低。為避免處理要求時發生延遲，來源應以相當保守的壓縮等級 (例如 Brotli-4) 壓縮動態資源；您可以使用 Brotli-11 壓縮靜態資源。如果來源不支援 Brotli，gzip-6 可用於壓縮動態資源；gzip-9 可用來壓縮靜態資源。
TLS 1.3
TLS 1.3 是最新版的傳輸層安全標準 (TLS)，這是 HTTPS 採用的加密編譯通訊協定。與 TLS 1.2 相比，TLS 1.3 的隱私保護與效能較佳。
TLS 1.3 可以將 TLS 握手從兩次往返縮短至同一時間。如果是使用 HTTP/1 或 HTTP/2 的連線，只要將 TLS 握手縮短至一往返，即可有效將連線設定時間縮短 33%。
HTTP/2 和 HTTP/3
HTTP/2 和 HTTP/3 兩者都會比 HTTP/1 提供效能優勢。兩者相比，HTTP/3 具備更高的「潛在」效能優勢。HTTP/3 尚未完全標準化，但一旦發生這個情況，即可廣泛支援。
HTTP/2
如果 CDN 預設為未啟用 HTTP/2，建議您啟用此功能。HTTP/2 提供比 HTTP/1 更多的效能優勢，且所有主要瀏覽器都支援。HTTP/2 的效能功能包括：多工處理、串流優先順序和標頭壓縮。
多工處理
多工處理可說是 HTTP/2 最重要的功能。多工處理可讓單一 TCP 連線同時提供多個要求/回應組合。如此可省去不必要的連線設定負擔；由於瀏覽器在一定時間內能夠開啟的連線數量有限，因此瀏覽器現在能夠同時要求更多網頁資源。理論上理論上來說，多工處理可以省去串連 HTTP/1 最佳化 (例如串連和合併工作表) 的需求。然而，在實務上，由於大型檔案壓縮較佳，這些技術仍保持相關。
串流優先順序
多工處理可以進行多個並行串流；串流優先順序提供介面，用於傳達這些串流的相對優先順序。以便伺服器優先傳送最重要的資源，即使資源並未先要求也可以。
串流優先順序是由瀏覽器透過相依樹狀結構表示，而且只是「偏好設定」的陳述式：換句話說，伺服器沒有義務滿足瀏覽器提供的優先順序 (或甚至考慮)。當網站更多透過 CDN 提供時，串流優先順序會變得更加有效。
HTTP/2 資源優先順序的 CDN 實作方式大不相同。如要判斷您的 CDN 是否完整且正確支援 HTTP/2 資源優先順序，請參閱「HTTP/2 很快了嗎？」一文。
雖然將 CDN 執行個體切換至 HTTP/2 主要只要切換開關，請務必先徹底測試這項變更，再開始在實際工作環境中啟用。HTTP/1 和 HTTP/2 都使用相同的要求和回應標頭的慣例，但是在不符合這些慣例的情況下，HTTP/2 指定的結構會遠不大。因此，啟用 HTTP/2 後，非規格的做法 (例如在標頭中加入非 ASCII 或大寫字元) 可能會開始導致錯誤。如果發生這種情況，瀏覽器嘗試下載資源時會失敗。開發人員工具的「網路」分頁中會顯示下載失敗的嘗試。此外，控制台會顯示「ERR_HTTP2_PROTOCOL_ERROR」錯誤訊息。
HTTP/3
HTTP/3 是 HTTP/2 的後續版本。自 2020 年 9 月起，所有主要瀏覽器都支援 HTTP/3，部分 CDN 也支援。效能是經由 HTTP/2 使用 HTTP/3 的主要優點。具體來說，HTTP/3 避免在連線層級進行隊頭封鎖，縮短連線設定時間。
消除行頭封鎖機制
HTTP/2 導入了多工處理功能，可讓單一連線同時傳送多個資料流。但在 HTTP/2 中，單一捨棄封包會封鎖連線中的所有串流 (這種情況稱為線頭阻斷)，使用 HTTP/3 時，捨棄的封包只會封鎖單一串流。主要是由於 HTTP/3 使用 UDP (HTTP/3 透過 QUIC) 使用 UDP，而非 TCP，因此，在資料傳輸在壅塞或有損的網路時，HTTP/3 特別實用。
縮短連線設定時間
HTTP/3 使用 TLS 1.3，因此共享其效能優勢：建立新連線只需往返一次，恢復現有連線時，也不需要往返。
HTTP/3 會對網路連線品質不佳的使用者造成最大的影響：由於 HTTP/3 能處理封包遺失率比前台更佳，而且因為在低延遲網路中設定 0-RTT 或 1-RTT 連線可節省的絕對時間，會有更多時間。
圖片最佳化
CDN 圖片最佳化服務通常著重於可自動套用的圖片最佳化服務，以降低圖片轉移大小。例如：去除 EXIF 資料、套用無損壓縮，以及將圖片轉換為較新的檔案格式 (例如 WebP)。網頁大小的傳輸位元組數約為圖片傳輸的位元組數約 50%，因此最佳化圖片可大幅縮小網頁大小。
壓縮
壓縮功能會移除 JavaScript、CSS 和 HTML 中不必要的字元。最好在原始伺服器 (而非 CDN) 進行壓縮。網站擁有者對於要壓縮的程式碼擁有更多相關資訊，因此通常比 CDN 所使用的更積極的壓縮技術。不過，如果無法縮小來源的程式碼，則建議使用 CDN 壓縮。
結語
- 使用 CDN：CDN 可快速傳遞資源、降低來源伺服器的負載，在處理尖峰流量時相當實用。
- 盡可能積極快取內容：靜態和動態內容都可以快取，但對於不同的持續時間，仍應快取。定期稽核您的網站，以確保您以最佳方式快取內容。
- 啟用 CDN 效能功能：Brotli、TLS 1.3、HTTP/2 和 HTTP/3 等功能可進一步提升效能。