HTTP 壓縮如何選擇 gzip、Brotli 或 zstd？瀏覽器、CDN 與快取

用戶端可列出能解壓縮的內容編碼，伺服器再按支援、內容及設定選擇回應。以下只是 HTTP/1.1 標頭摘錄；HTTP/2 和 HTTP/3 有相同語意的欄位，但傳輸框架不同。

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

即使請求列出 zstd，伺服器仍可能按檔案類型、CPU 負載、快取及 CDN 規則選擇 Brotli、gzip 或未壓縮表示。

RFC 9110 區分了幾種情況：沒有 Accept-Encoding 欄位表示任何內容編碼均可接受；欄位值為空則表示不希望使用內容編碼。q=0 表示拒絕，* 對應沒有明確列出的方式。

未壓縮表示通常可接受，但 identity;q=0，或沒有更具體 identity 指定的 *;q=0，可以將它排除。偏好要按權重等規則判斷，不能只按列出次序推斷。

gzip 採用 DEFLATE；Brotli 在預先壓縮的靜態網頁資源上有實用價值；zstd 已廣泛用於資料系統、套件及儲存，再延伸至 HTTP。這些特性不代表某一種方式在所有輸入和設定下都勝出。

Zstandard 源自 Meta/Facebook，是無損壓縮格式。RFC 8878 定義其格式及 application/zstd 媒體類型，IANA 也已登記 HTTP 的 zstd 內容編碼。

2024 年的 RFC 9659 為 HTTP 用途訂明視窗限制：編碼端不得產生需要超過 8 MB Window_Size 的框架；解碼端必須支援直至並包括 8 MB 的視窗。

這是為互通而設的視窗要求，不是整份壓縮檔或 HTTP 回應最多只能有 8 MB。格式成熟與傳送環境是否具備支援，仍要分開判斷。

zstd 結合 LZ77 類型的字典參照及快速熵編碼，並提供廣泛壓縮級別，以平衡運算時間和壓縮率。解壓縮速度也是它用於傳送和儲存的考量之一。

網頁效能不只取決於傳送多少位元組，也包括使用者裝置解壓縮所需時間。動態回應或 JSON API 可以把 zstd 納入比較，但仍要用實際內容、壓縮級別及硬件量測。

HTML、CSS、JavaScript、JSON 和文字記錄通常較容易再壓縮；JPEG、PNG、AVIF、WebP、ZIP 或已內部壓縮的 PDF，可能幾乎沒有收益，甚至令大小和 CPU 成本增加。

靜態 JS 和 CSS 可以在建置時預先用 Brotli 壓縮，傳送時便毋須再次執行壓縮。zstd 的速度特性則令它成為動態內容的候選方式。

例如靜態檔用 Brotli、頻繁變更的 JSON 用 zstd、舊用戶端保留 gzip，是可以量測的配置，卻不是通用最優答案。即使同屬靜態或動態內容，結果也會隨輸入、級別、CPU 和快取條件改變。

應比較實際回應大小、CPU 時間、快取命中率及使用者瀏覽器分佈，而非按個人偏好挑選壓縮名稱。

Content-Type 說明表示的媒體類型，Content-Encoding 則列出套用在表示上的內容編碼。例如：

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

能處理該編碼的 HTTP 用戶端會先解壓縮，再按 JSON 處理。這與下載一個 .zst 檔案有關，但並非同一件事。

內容編碼亦不同於 Transfer-Encoding 對訊息傳輸所作的處理。若套用多層內容編碼，標頭按套用順序列出，解碼時則以相反次序還原。

同一 URL 可能對某個用戶端回傳 br，對另一個回傳 gzip 或 zstd。快取因此需要辨認與 Accept-Encoding 有關的表示差異：

Vary: Accept-Encoding

若 CDN、反向代理或應用程式沒有正確處理，可能把 zstd 回應送到無法解碼的用戶端。自行設定 Nginx 或伺服器時，要檢查快取鍵及 Vary，而非假設每個中介層都會自動處理。

Vary 是選擇不同表示的資訊，不會單獨授權儲存或共享回應。Cache-Control、認證、狀態碼等儲存及重用條件仍須另行評估。

以下按 2026 年 9 月 5 日查核的官方文件及兼容數據整理。最低支援版本只是起點，實際仍要查看請求與回應標頭：

Cloudflare 文件所列的預設方式為 Free 使用 zstd、Pro／Business 使用 Brotli、Enterprise 使用 gzip，但實際結果仍受請求和規則影響。來源端和訪客端是不同區段，必須分別驗證。

若同一回應混合機密資料和攻擊者可控制的輸入，壓縮後大小可能形成資訊洩漏途徑。HTTPS 不能自動消除這類風險，需按回應內容及威脅模型評估。

zstd 的格式、HTTP 登記及視窗條件已有明確依據，適合按環境納入評估。gzip 的兼容性及 Brotli 在靜態資源上的價值仍然存在，沒有必要只保留一種方式。

採用前，使用自己網站的 HTML、CSS、JavaScript 和 JSON API 比較壓縮後大小、CPU 時間、解壓縮及快取結果，再配合實際瀏覽器分佈決定。量測時也要固定壓縮級別與基礎設施條件，讓結果可以重現。