[WP] Gzip vs Brotli 壓縮：2 種壓縮演算法的差異

要讓包括 WordPress CMS 在內的網站變快，在伺服器上設定資料壓縮很有幫助。這樣一來，網頁伺服器與瀏覽器之間傳輸的資料就能更快載入，網站的速度也會變得更快。這是經營網站的管理員經常考慮的因素之一。gzip 壓縮的使用相當普遍，許多網頁伺服器也正逐漸從 gzip 改用 Brotli 壓縮，這樣的趨勢正持續增加。

1️⃣ 什麼是壓縮？

網站 URL 連線時，瀏覽器與伺服器之間就會開始對話。此時，瀏覽器會向伺服器傳達自己能否解開內容的壓縮（Compression），以及使用哪些壓縮演算法等資訊。這能幫助瀏覽器在伺服器傳送壓縮過的資料時，正確地加以解壓縮。因此，只要使用支援壓縮演算法的伺服器與瀏覽器，就能讓網站的載入速度更快。

網頁瀏覽器連上伺服器時，會送出 gzip 壓縮或 Brotli 壓縮這類標頭。以兩者之一壓縮過的資料會輸出到瀏覽器，而壓縮過的資料比未壓縮的資料載入得更快。

Content-encoding: gzip
Content-encoding: br

被壓縮的檔案主要是文字檔。
· HTML
· CSS
· JavaScript

2️⃣ 什麼是 Gzip 壓縮？

網站主機業者常用的一般壓縮演算法是 Gzip 與 Brotli。Gzip 在 1992 年推出測試版，1993 年發布 1.0 版。一般來說 Gzip 是在網際網路上傳輸資料時，用來壓縮的標準壓縮方法之一。這個方法以早期的壓縮演算法 DEFLATE 壓縮為基礎，名稱則取自先前為 Unix 開發的檔案壓縮程式 gzip。

DEFLATE 壓縮是結合 LZ77（Lempel-Ziv 1977）演算法與 Huffman 編碼方式的壓縮方式。LZ77 會搜尋重複的資料、找出相符的字串，再把該字串替換成代碼來進行壓縮。Huffman 編碼方式則是利用每個字元出現的頻率，分配最短的位元碼來進行壓縮。

Gzip 使用 DEFLATE 壓縮方式壓縮資料，並在 HTTP 請求與回應中使用「Accept-Encoding: gzip」標頭，只在客戶端支援 Gzip 壓縮時才進行壓縮。藉由這種方式執行資料壓縮，就能提升網站的載入速度。

3️⃣ 什麼是 Brotli 壓縮？

Brotli 壓縮是由 Google 員工 Jyrki Alakuijala 與 Zoltán Szabadka 在 2013 年開發的。

Gzip 原本是為了壓縮檔案而設計的， 後來才修改成也能在網頁上使用。相對地，Brotli 壓縮則是 以在網頁上使用為目的而開發的。因此，使用 Brotli 時，網頁伺服器可以在把內容傳送到瀏覽器之前先進行壓縮。由於在串流到瀏覽器之前就已經壓縮，所以是更好、更進步的方式。

Brotli 壓縮使用與 GZIP 壓縮相同的 LZ77 與 Huffman 編碼方式這兩項核心基本技術。

4️⃣ Gzip 壓縮 vs Brotli 壓縮

Gzip 使用 DEFLATE 方式，Brotli 則使用在 LZ77 與霍夫曼編碼之上加入上下文建模的自有格式，來壓縮（& 解壓縮）資料。

• Gzip 的壓縮速度比 Brotli 快。
• Brotli 是專為網頁設計的。
• Brotli 在所有壓縮等級都提供更好的壓縮率（也就是產生更小的壓縮檔案）。
• Brotli 對 3 種檔案的壓縮率比 Gzip 更好，分別是 HTML 21%、CSS 17%、JavaScript 14%。

比起 Gzip，偏好 Brotli 的網頁伺服器越來越多。Brotli 的設計是即時壓縮串流，因此據說與 Gzip 相比，前端整體的解壓縮速度最多快 64%。

1996 年 5 月發布的 RFC 1952 說明，Gzip 格式使用 DEFLATE 壓縮方式，並包含用來檢查資料損毀的 CRC 值。壓縮後的資料結尾會記錄原始資料的 CRC-32 值與大小。

2016 年 7 月發布的 RFC 7932 寫道，Brotli 結合 LZ77 演算法與霍夫曼編碼進行壓縮。此外，它會以壓縮前資料的前兩個位元組作為上下文來選擇霍夫曼碼，也可以不用重複字串，改為參照大小 122,784 位元組的靜態字典中的單字。

兩種格式會在回應標頭中顯示為 [Content-Encoding: gzip] 與 [Content-Encoding: br]。[br] 這個值是在 RFC 7932 中註冊為 HTTP 內容編碼的。

5️⃣ Gzip 壓縮與 Brotli 壓縮實測：Nginx + Apache 伺服器

在同時使用 Nginx 與 Apache 的 WordPress 伺服器上，只改變請求標頭，比較了同一篇文章、WordPress 預設區塊 CSS 檔案與 jQuery 檔案的回應。在 [Accept-Encoding] 中只放 gzip 的請求、只放 br 的請求，以及沒有標頭的請求，都是在同一台伺服器上用 curl 送出的。

for ae in gzip br ''; do echo == ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/hello-world/ | grep -i -E '^(content-encoding|size)'; done

== gzip
content-encoding: gzip
size: 21390
== br
content-encoding: br
size: 20190
== none
size: 90833

一篇文章的 HTML，在 gzip 請求中壓縮為 21,390 位元組，在 br 請求中壓縮為 20,190 位元組，沒有標頭的請求則回應未壓縮的 90,833 位元組。br 回應比 gzip 小 1,200 位元組（5.6%）。

for f in wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do for ae in gzip br ''; do echo == ${f##*/} ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/$f | grep -i -E '^(content-encoding|size)'; done; done

== style.min.css gzip
content-encoding: gzip
size: 19655
== style.min.css br
size: 140829
== style.min.css none
size: 140829
== jquery.min.js gzip
content-encoding: gzip
size: 30633
== jquery.min.js br
size: 87553
== jquery.min.js none
size: 87553

在 gzip 請求中，CSS 檔案壓縮為 19,655 位元組，jQuery 檔案壓縮為 30,633 位元組。只要求 br 或沒有標頭時，則不帶 [Content-Encoding] 標頭，直接回應 140,829 位元組與 87,553 位元組的原始檔。

nginx -V 2>&1 | grep -c brotli

0

httpd -M 2>/dev/null | grep -E 'brotli|deflate'

 deflate_module (shared)
 brotli_module (shared)

CSS 與 JS 這類靜態檔案由 Nginx 直接回應並壓縮，而這個架構的 Nginx 沒有 Brotli 模組，所以只用 gzip 壓縮。

HTML 則是由 WordPress 回應 Nginx 轉給 Apache 的請求，再由 Apache 壓縮。Apache 同時有 Brotli 模組與負責 Gzip 壓縮的 [mod_deflate] 模組。

for f in hello-world/ wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do echo == $f; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H 'Accept-Encoding: gzip, deflate, br, zstd' https://example.com/$f | grep -i -E '^(content-encoding|size)'; done

== hello-world/
content-encoding: gzip
size: 21390
== wp-includes/css/dist/block-library/style.min.css
content-encoding: gzip
size: 19655
== wp-includes/js/jquery/jquery.min.js
content-encoding: gzip
size: 30633

伺服器有 Brotli 模組，並不代表瀏覽器就會收到以 Brotli 壓縮的回應。以與 Edge 155 送出的值相同的 [gzip, deflate, br, zstd] 送出請求後，Apache 也以 gzip 壓縮 HTML，三個檔案都以 gzip 回應。

即使把 br 放在 gzip 前面，或像 [br;q=1.0, gzip;q=0.5] 這樣標明優先使用 br，HTML 仍然以 gzip 回應。用 Edge 開啟同一篇文章與兩個檔案時，也全都以 gzip 傳送。

首位元組時間是打亂請求順序、各測 40 次的 curl [time_starttransfer] 值的中位數；每次請求都重新連線，因此也包含 TLS 連線時間。HTML 的未壓縮回應為 22.7ms、gzip 26.3ms、br 26.5ms，與瀏覽器相同的請求為 25.0ms。CSS 與 JS 無論是否壓縮，都在 18～21ms。

Gzip 與 Brotli 的壓縮速度並未實際測量，而是以公開資料比較。RFC 7932 寫道，Brotli 的壓縮率明顯高於 gzip 程式，解壓縮速度也比目前的 LZMA 實作快得多。Google 在 Brotli 儲存庫中說明，Brotli 的速度與 deflate 相近，但壓縮得更緊密。

2015 年，Cloudflare 用 10,655 個 HTML、CSS、JavaScript 檔案測試了兩種方式。Brotli 最高品質的結果平均比 zlib 最高品質小 1.19 倍，但壓縮速度為每秒 0.5MB，遠比 zlib 等級 9 的 41.9MB 慢。Brotli 等級 4 的壓縮率與 zlib 等級 8 相近，整體平均稍快，但只看小於 64KB 的檔案時，則慢了 1.48 倍。

以上介紹了透過壓縮 HTML、CSS、JavaScript 等檔案來優化網站的過程。要提升網站速度，檔案壓縮與 圖片優化可以說是不可或缺的要素之一。

🔢 FAQ & 推薦內容

ℹ️ 聯盟行銷說明
本站內容包含聯盟行銷連結。訪客透過這些連結購買商品或服務時，本站會從賣家獲得佣金。在這個過程中，購買者支付的金額^{（遇到活動折扣時金額會降低↓）}並不會因此提高。刊登的價格、折扣與庫存資訊以撰寫當時為準，可能與實際情況不同，購買前請向賣家做最後確認。商品的挑選與評價依本站自訂的標準撰寫，是否支付佣金不會影響介紹順序或評價內容。