gzip、Brotli、zstd 怎麼選？HTTP 壓縮協商與部署條件

用戶端可以列出多個可接受的方式，伺服器再依能力和傳送政策，選擇可接受的表現形式：

GET /app.js HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, br, zstd

HTTP/1.1 200 OK
Content-Type: application/javascript
Content-Encoding: br

這是 HTTP/1.1 形式的標頭節錄。HTTP/2 和 HTTP/3 保留相同欄位語意，但傳輸時的訊框格式不同。要求列出 zstd，不代表伺服器就必須用 zstd 回覆。

依 RFC 9110，沒有 Accept-Encoding 欄位表示任意內容編碼都可接受；欄位存在但值為空，則表示不希望使用內容編碼。q=0 表示拒絕；* 對應未明確列出的方式。未編碼的 identity 通常可接受，除非以 identity;q=0，或沒有更明確 identity 項目的 *;q=0 排除。不要只按列出順序推斷偏好。

gzip 的相容性、Brotli 的文字壓縮能力，以及 zstd 的速度／壓縮率取捨，都是評估起點，卻不能推導出適用所有輸入的贏家。

Zstandard 也用於套件散布、日誌和儲存系統。格式本身是否成熟，與某條網頁傳送路徑是否啟用它，是兩個不同問題。

RFC 8878 定義 Zstandard 格式及 application/zstd 媒體類型；IANA 也登錄了 HTTP 的 zstd 內容編碼。

RFC 9659 明確規定 HTTP 使用的視窗條件：編碼器不得產生需要超過 8 MB Window_Size 的訊框，解碼器必須支援到包含 8 MB 的視窗。這限制的是解碼視窗，不是整份壓縮檔或 HTTP 回應的總大小。

因此，支援 zstd 格式還不夠，也要符合 HTTP 情境的限制。能用在其他應用程式的 zstd 資料串流，不一定適合直接當成瀏覽器回應。

Zstandard 結合字典式比對與熵編碼，提供多種壓縮等級。提高等級可能以更多編碼工作換取較小體積；較快的設定則可能適合請求發生時才執行的壓縮。

解碼耗時也很重要。少傳一些位元組，不代表頁面一定更快，因為處理成本可能抵銷傳輸收益。應使用服務實際提供的內容與大小進行測量。

HTML、CSS、JavaScript、JSON 和日誌通常容易壓縮。JPEG、PNG、AVIF、WebP、ZIP，以及許多 PDF 已在內部壓縮，再加一層可能收益很小，甚至增加大小或 CPU 負擔。

靜態資源可以事先壓縮，將較昂貴的編碼工作移到傳送前。因此，高壓縮等級的 Brotli 是靜態 JavaScript、CSS 的一種實用選項。

編碼速度重要時，zstd 也可能適合某些動態回應。例如部分資源使用 Brotli、合適的 API 回應使用 zstd，再保留 gzip 相容性，是可以評估的組合。

這是部署政策的例子，不是協定規則。判斷前要比較版本、等級、輸入資料、CPU 工作量、解碼耗時及快取行為，不能只因為內容是靜態或動態就下結論。

Content-Type 指出媒體類型，Content-Encoding 描述套用在該表現形式上的編碼：

Content-Type: application/json
Content-Encoding: zstd

接收端先解開內容編碼，再依媒體類型把結果解讀為 JSON。因此，下載一個 .zst 檔案，與接收 zstd 編碼的 JSON，是相關但不同的用途。

Content-Encoding 也不同於 Transfer-Encoding 的訊息傳輸處理。若套用多個內容編碼，標頭依套用順序列出，解碼時則依相反順序還原。

同一個網址可能向不同用戶端回傳 Brotli、gzip 或 identity。快取必須避免重用對方無法解碼的版本；回應可以指出選擇版本時參考的要求欄位：

Vary: Accept-Encoding

CDN 或反向代理可能在內部正規化、管理不同編碼版本。自行設定快取時，要一起檢查快取鍵與回應中繼資料，避免將不相容的版本送給用戶端。

Vary 本身不代表允許儲存或共享回應。Cache-Control、驗證資訊、狀態碼及其他快取規則仍要遵守。「選到正確版本」和「獲准重用回應」是不同條件。

以下整理 2026 年 9 月 5 日查核的官方文件與相容性資料。除了產品宣稱，還要查看實際路徑上的要求與回應標頭。

Cloudflare 文件列出的預設方式是 Free 使用 zstd、Pro／Business 使用 Brotli、Enterprise 使用 gzip；實際選擇仍會受到訪客要求與壓縮規則影響。來源端和訪客端是不同區段，應分別驗證。

若同一回應包含秘密資訊與攻擊者可控制的輸入，壓縮後大小可能洩漏資訊。HTTPS 不會自動消除這項風險；啟用壓縮前仍應評估回應內容與威脅模型。

即使 zstd 已獲支援，gzip 和 Brotli 仍有用途。格式規格、HTTP 限制、用戶端支援及傳送政策，各自回答不同問題。

使用實際 HTML、CSS、JavaScript 和 JSON，比較傳輸大小、編解碼成本、快取行為及讀者的用戶端分布。像二進位編輯器這類工具可以檢視位元組，但不能代替壓縮效能測試。

選擇適合該路徑的組合，記錄使用的版本與設定；重新評估部署時，再確認產品的支援現況。