本頁面提供透過 Cloud CDN 最佳化和加速內容傳遞的最佳做法。以下各節分為幾個主要領域。
Cloud CDN 使用外部應用程式負載平衡器做為可快取內容的來源。外部應用程式負載平衡器可透過一個全球 IP 位址，經由下列類型的後端，將混合靜態和動態產生的內容傳遞給使用者：
- 執行個體群組
- 區域網路端點群組 (NEG)
- 無伺服器 NEG：一或多項 App Engine、Cloud Run 或 Cloud Run functions 服務
- 外部後端的網際網路 NEG
- Cloud Storage 中的 bucket
由於 Cloud CDN 與 Google Cloud完美整合，您可透過多種方式部署 Cloud CDN 並管理內容。請使用下列最佳做法，規劃及修正您的部署方式。詳情請參閱「設定 Cloud CDN」。
充分提高快取命中率
建議採用下列做法，盡可能提高快取命中率。
快取靜態內容
啟用 Cloud CDN 時，提升效能的最佳做法，是選擇應用程式適合的快取模式。
如要管理快取規則，使用快取控制項標頭，是最具彈性且一般人喜愛的方法。如果您不熟悉來源快取控制項標頭的使用方式，建議允許 Cloud CDN 自動快取靜態內容。
如要自動從來源快取靜態回應，可以使用 --cache-mode=CACHE_ALL_STATIC 設定 (預設)。如果來源沒有在回應標頭中指定任何快取指令，這項設定可讓 Cloud CDN 快取常見的靜態內容類型。請確認內容符合上述類別，否則系統不會快取內容。
請勿快取使用者專屬內容
某些情況下，瀏覽器可能會快取使用者專屬內容。請勿使用 Cloud CDN 快取使用者專屬內容。
使用自訂快取金鑰來提升快取命中率
為了確保效能和擴充性，盡可能提高快取命中率相當重要。根據預設，Cloud CDN 會使用完整的要求網址來建構快取金鑰。如要充分提高快取命中率，可使用自訂快取金鑰，避免 Cloud CDN 將快取資料過度分割。
自訂快取金鑰可用於加入或省略任何通訊協定、主機和查詢字串的組合。以下列舉幾個可使用自訂快取鍵的情況：
假設您有兩個主機解析為相同 IP 位址，且前往同一個服務。在這個例子中，整個網站在兩個主機上完全相同。根據預設，HTTP 要求中的
Host:標頭不同，因此 Cloud CDN 會快取兩個副本。使用自訂快取金鑰，就能讓 Cloud CDN 忽略要求的主機部分，並共用快取項目。舉個更具體的例子：假設您有兩個不同網域的網站，雖然兩者的內容不同，但是共用相同的公司標誌，而這些共用內容是透過專用的後端服務提供。在存放該標誌的後端服務中啟用 Cloud CDN 和自訂快取金鑰時，請取消勾選「Host」(主機) 核取方塊，讓快取在忽略網域的情況下快取標誌。
無論標誌是透過 HTTP 或 HTTPS 顯示，都必須經過快取，因此，在存放該標誌的後端服務中自訂快取金鑰時，請取消勾選「Protocol」(通訊協定) 核取方塊，將透過 HTTP 和 HTTPS 發出的要求，都視為符合該標誌的快取項目。
如要瞭解如何自訂快取金鑰，請參閱「使用快取金鑰」。
發揮最大效能
建議採用下列做法，發揮最大效能。
務必啟用 HTTP/3 和 QUIC 通訊協定支援
HTTP/3 是新一代網際網路通訊協定，以 QUIC 為基礎所建構，而 QUIC 則是從原始的 Google QUIC (gQUIC) 通訊協定發展而來。外部 HTTP(S) 負載平衡器、Cloud CDN 和用戶端之間支援 HTTP/3。
如要透過 Cloud CDN 提升效能，請務必啟用 HTTP/3。
使用 negative caching
negative caching 可針對常見錯誤或重新導向精細控管快取功能。Cloud CDN 遇到特定回應代碼時，會根據設定的存留時間將回應保留在快取中。這麼做可減少來源的負載量，並縮短回應延遲時間來改善使用者體驗。
啟用 TLS 早期資料
使用 TLS 早期資料，可將連線恢復率提高 30% 至 50%。如要啟用 TLS 早期資料，請在 gcloud compute target-https-proxies update 指令中使用 tls-early-data 選項。詳情請參閱「設定 TLS 早期資料」。
您可以在 STRICT 或 PERMISSIVE 模式中啟用 TLS 早期資料。
STRICT：對不含其他查詢參數的冪等方法 (GET、HEAD、OPTIONS和TRACE) 啟用早期資料。這個方法較安全，適用於大多數情況。PERMISSIVE：對包含查詢參數的冪等方法啟用早期資料。使用這個模式時，請務必密切監控應用程式的行為和資安態勢。
如果早期資料要求使用非冪等 HTTP 方法或含有查詢參數，系統會拒絕要求，並傳回 HTTP 425 狀態碼。
充分提高安全性
建議採用下列做法，盡可能提高安全性。
使用 Google Cloud Armor
Cloud Armor 與 Cloud CDN 整合，適用於已快取和未快取或快取失敗的內容。建議盡可能搭配使用 Cloud Armor 和 Cloud CDN，提高網頁應用程式的安全性。
使用已簽署的網址
如果您使用已簽署的網址，請注意下列事項：
將公開和私人內容分別存放在不同的 Cloud Storage bucket。
遵循安全性最佳做法。
驗證私人來源
來源驗證可有效確保要求只來自您設定的後端服務，還能保護要求的傳輸中資料，避免重複使用要求中已簽署的部分。
建議針對 Amazon S3 儲存貯體或相容物件儲存庫使用私人來源驗證。私人來源驗證可確保只有受信任的連線能存取私人來源的內容，且使用者無法直接存取。
此外，如果原始防火牆禁止存取來源，請使用 IP 允許清單，確保要求來自 Cloud CDN 或外部應用程式負載平衡器。不過，此做法無法阻止其他 Media CDN 客戶在自己的設定中指定您的來源，進而嘗試存取您的內容。
最佳化快取
建議採用下列做法，進一步最佳化快取。
最佳化快取存留時間
您可以設定或覆寫存留時間，微調 Cloud CDN 快取回應的時間長度，以及 Cloud CDN 重新驗證回應的時間。
您也可以定義用戶端可使用的存留時間，充分利用瀏覽器快取。
詳情請參閱「使用存留時間設定和覆寫」。
為具時效性的內容設定到期時間
Cloud CDN 快取中每部分的內容都設有相關的到期時間，請務必根據您的用途設定合適期限。當快取伺服器上的內容到期，原始伺服器就必須重新傳送，所以請務必慎選到期時間。
選擇到期時間的其中一種方法，是根據內容更新頻率來分類內容，舉例來說：
- 近乎即時更新，例如運動賽事或交通狀態的現行動態饋給
- 頻繁更新，例如每週、每日或每小時天氣訊息或頭版新聞圖片
- 不常更新，例如網站標誌或 CSS/JavaScript 檔案
接下來請依照內容類別選擇到期時間。比方說，5 秒到期可能適合近乎即時的運動賽事得分資訊，而一小時到期則適用於天氣更新。如要為儲存在 Cloud Storage 中的內容設定到期時間，請使用 Cache-Control 中繼資料。若內容是經由 Compute Engine 提供，可以設定網路伺服器軟體來控制到期時間。
到期時間是透過 Cache-Control 標頭中的 max-age 和 s-maxage 值指定，而這個標頭由 HTTP 規格定義。舉例來說，下列 Cache-Control 標頭會將相關聯的內容設為可公開讀取且可快取，快取期限為 72 小時 (259200 秒)：
Cache-Control: public, max-age=259200
如要讓快取發揮最大效益，請依照「快取總覽」文中的指示操作。請注意，Cache-Control 中繼資料欄位中的 max-age 值和 s-maxage 值，會透過下列方式共同發揮作用：
max-age和s-maxage值以秒為單位。s-maxage值僅適用共用快取，不適用瀏覽器快取。max-age值會套用至所有快取 (除非遭s-maxage覆寫)。
如果內容不常變更，或是須與相關內容一起變更，通常適合搭配使用較長的到期時間和以版本管理的網址。
使用以版本管理的網址來更新內容
內容版本管理功能可提供相同內容的不同版本，在快取項目到期前向使用者顯示新內容，有效移除舊版內容。版本管理功能可免費使用，建議將這項功能設為更新可快取內容的預設方法。
如要管理內容版本，請在網址中新增版本編號這類參數。在網址中新增參數的方式有許多種，例如：
新增查詢字串：
file.ext?v=100。如果使用後端 bucket，用於版本管理的任何查詢字串，都必須在後端 bucket 的設定中指定。詳情請參閱「Cloud Storage 快取金鑰的查詢字串納入清單」。
更改檔案名稱：
file.1.0.0.ext或file_v100.ext。更改路徑：
/v100/file.ext。
新增參數時，請變更檔案名稱及網址，強制快取忽略任何現有的快取項目。
請謹慎使用撤銷功能來移除內容
撤銷功能會在快取項目到期前，將內容從 Cloud CDN 分散式快取伺服器中移除。撤銷作業具有最終一致性。
建議您謹慎使用撤銷功能，只有在不得已的情況下才使用。比方說，因法律因素或意外上傳而須移除內容時，撤銷功能就相當實用。其他情況下，建議您盡可能使用版本管理功能，或是等待內容自然到期。Cloud CDN 快取伺服器會定期移除不常存取的內容，以挪出空間存放新內容。30 天未存取的內容將無條件移除。
快取撤銷功能有頻率限制。
如要進一步瞭解撤銷功能，請參閱快取撤銷總覽。
確保上傳檔案的一致性
建議採用下列做法，確保上傳檔案的一致性。
避免更新現有檔案
請上傳新版本，而非更新現有檔案。
新檔案請使用不重複的名稱，可包含版本編號或日期。在檔名後附加版本編號 (例如 file_v2.css) 或日期 (例如 file_20230806.js)，有助確保 Cloud CDN 擷取正確的更新版本。不建議在檔案網址後附加參數 (例如 file.css?v=2) 來強制擷取新版本，因為如果不是對來源檔案執行不可分割的完整更新，仍可能會快取到部分或不完整的檔案。
請務必先上傳新版本的依附元件，再上傳參照這些依附元件的檔案。此做法可確保所有參照的檔案都是完整且最新的版本，降低提供部分更新或截斷檔案的風險。
對檔案執行不可分割的完整更新
如需更新現有檔案，請執行不可分割的完整更新。
如果系統存取並快取了尚未完成上傳的檔案，可能會快取到不完整或截斷的檔案。舉例來說，/index.html 等檔案無法擁有不重複名稱，但可以指向其他具有不重複名稱的檔案。
如果以目標名稱上傳檔案，當使用者在上傳期間存取檔案，系統可能會快取不完整的檔案。請改以臨時名稱上傳檔案，上傳完成後再重新命名為目標名稱，這麼做可確保參照時檔案立即完全可用。
更新現有檔案時，位元組範圍快取可能會導致 Cloud CDN 在新檔案上傳之後，仍保留舊版檔案的範圍。如果 Cloud CDN 已快取舊版檔案的範圍，要求遺失的區塊可能會導致傳回部分回應。這是因為 etag 或 last-modified 變更，導致 Cloud CDN 判斷原始檔案已變更，進而刪除所有過時內容、中斷所有進行中的下載作業，並產生錯誤訊息，提示用戶端重試。如要緩解這個問題，請找出正在更新的位元組範圍快取檔案，發出撤銷指令。
充分發揮 Monitoring 和 Logging 的效用
建議採用下列做法，充分發揮 Monitoring 和 Logging 的效用。
務必為 Cloud CDN 啟用記錄功能
管理 Cloud CDN 的最佳做法，是確實為所有採用 Cloud CDN 的後端啟用記錄功能。
使用 Cloud CDN 的自訂監控資訊主頁
為了確保可靠性和效能提升，最佳做法是定期查看與 Cloud CDN 相關的監控指標。建議您先從 Cloud CDN 自訂監控資訊主頁著手。
查看第三方效能測試結果
查看第三方供應商的報告，例如 Citrix Radar 提供的可用性、延遲和處理量報告。