WordPress GZIP 教學，先檢查壓縮再調整設定

Facebook Line Messenger Telegram

WordPress 的 GZIP 壓縮會縮小 HTML、CSS、JavaScript 等內容的傳輸量。啟用前，先檢查實際回應：看到 Content-Encoding: br 或 zstd，也代表使用了壓縮，並不是少了 GZIP 就需要補設定。

這篇教你先確認瀏覽器收到什麼，再按主機、外掛與 CDN 的分工處理。若目前已正常壓縮，就把時間留給真正拖慢網站的資源；若尚未壓縮，再修改負責那個回應的設定。

先檢查實際下載的回應

在 Chrome 開啟網站，按 Windows 的 F12 或 Mac 的 Command + Option + I，切到 Network。勾選 Disable cache，保持開發者工具開啟並重新載入，選取狀態為 200 的 HTML 文件，再到 Headers 查看 Response Headers。

請確認這次真的透過網路下載，而不是只看記憶體快取、磁碟快取或 Service Worker 回傳的內容。首頁看完後，再挑一份自己網站的 CSS 或 JavaScript 檢查；一個檔案有壓縮，不代表所有資源都用了同樣設定。

回應欄位	代表什麼	接下來怎麼做
`Content-Encoding: gzip`	內容以 GZIP 編碼。	頁面顯示正常即可，不需為了「再開一次」而加外掛。
`Content-Encoding: br`	內容以 Brotli 編碼。	這也是壓縮成功的回應。
`Content-Encoding: zstd`	內容以 Zstandard 編碼。	確認用戶端支援且頁面正常，不必硬改成 GZIP。
沒有 `Content-Encoding`	這次回應未透過此欄位宣告內容編碼。	先看資源型別、大小、狀態與來源，再判斷是否需要壓縮。

瀏覽器用 Accept-Encoding 告知能接受哪些格式，伺服器則用 Content-Encoding 說明實際回傳的格式。兩個欄位的工作不同，MDN 的 Content-Encoding 說明列出了上述編碼；送出「支援 GZIP」的請求，本身不等於伺服器已經使用 GZIP。

用 curl 檢查，請取得 GET 回應

以下使用 macOS／Linux 終端機語法。可以執行這個指令，再把網址換成你要檢查的頁面或 CSS。它會送出 GET、顯示標頭並丟棄回應本文，沒有使用 -I 改送 HEAD。

curl -sS -D - -o /dev/null -H 'Accept-Encoding: gzip' https://techmoon.xyz/enable-gzip/

2026 年 9 月 8 日，這個網址的一次實際 GET 回應包含以下欄位：

HTTP/2 200
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
content-encoding: gzip

這表示該次 HTML 回應用了 GZIP。若經過 CDN，只能先確認訪客端收到的結果，還不能據此推論來源主機也採用同一格式。遇到 301 或 302，先確認 Location 指向的最終網址，再檢查真正內容的回應。

先確認哪一層負責壓縮

管理型 WordPress 主機、共享主機、自己維護的伺服器，能修改的地方不同。若不知道網站由 Apache、LiteSpeed、NGINX 或哪一層代理服務回應，先向主機商確認。目錄裡存在 .htaccess，不能單獨證明目前流量由 Apache 處理。

可以把問題直接交給客服：「這個網址的 HTML 與 CSS 由哪一層壓縮？我是否能修改相關設定？修改前要備份哪個檔案、發生問題如何還原？」還不熟悉主機與維護責任，可先讀虛擬主機資源與維護分工。

WP Rocket 的 GZIP 是自動功能

如果已使用 WP Rocket，官方將 GZIP 列為自動功能，不會在設定頁提供一個讓你勾選的 GZIP 開關。其壓縮文件說明，Apache／LiteSpeed 環境會透過 .htaccess 規則處理；NGINX 則需要相應的伺服器設定。安裝外掛不能讓每種主機都用同一套方式生效。

Cloudflare 壓縮要看訪客端與來源端

Cloudflare 的內容壓縮文件分開描述「來源主機到 Cloudflare」與「Cloudflare 到訪客」兩段，並支援在傳遞過程中解壓或重新編碼。因此，來源端使用 GZIP、訪客端收到 Brotli，是可能且正常的情況。

需要調整 Cloudflare 行為時，查看目前的 Compression Rules。規則選擇也會受瀏覽器可接受的編碼影響，來源回應的 Cache-Control: no-transform 則可能阻止規則改變內容。Auto Minify 與舊 Brotli 設定已列入官方棄用紀錄，不必再沿用舊教學尋找這兩個開關。

需要手動設定時，先備份再測試

以下範例適合已確認伺服器類型、具有設定權限，並能還原修改的站長。先保留原設定，一次調整一處；已有主機、外掛或 CDN 規則時，先確認現有分工，不要把不同範例全部貼上。

Apache：針對文字型別加入 DEFLATE

確認主機已載入 mod_deflate、mod_filter，且允許在 .htaccess 使用相應指令後，可在網站目錄加入以下規則。若檔案有 WordPress 自動維護的標記區段，把自訂規則放在那個區段外，並保留原檔備份。

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/css text/javascript application/javascript application/json application/xml image/svg+xml
</IfModule>

這是依Apache mod_deflate 文件整理的型別清單，沒有對所有檔案強制壓縮。模組內的 DEFLATE 過濾器產生的是 GZIP 編碼；正常運作時也會加入 Vary: Accept-Encoding，讓中間快取知道回應和用戶端支援的編碼有關。

這段規則已在本機隔離的 Apache 2.4.67 以靜態 CSS 驗證：接受 GZIP 時收到可正確還原的壓縮內容，要求原始內容時也能取得原檔。你的 WordPress、主機權限與其他規則仍可能不同，套用後要重新檢查實際頁面。

<IfModule> 是條件判斷，不會替主機安裝模組。模組沒有載入時，裡面的規則可能直接略過；因此「沒有報錯」也不能代替壓縮驗證。

NGINX：在對應的設定區塊處理

NGINX 不讀取 Apache 的 .htaccess 規則。對自行管理的 NGINX，可以依現有部署方式，在適當的 http、server 或 location 區塊評估下列基本設定：

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css text/javascript application/javascript application/json application/xml image/svg+xml;

1024 是這份範例選用的最小回應大小，並不是所有網站的最佳值。NGINX 官方文件說明，text/html 已包含在處理範圍，gzip_types 用來補上其他型別。這份最小範例沒有強制壓縮所有代理或帶驗證的回應；會員、結帳等動態內容應依現有安全與代理設定另行評估。

修改後，在實際使用該設定的環境執行 nginx -t。檢查通過，再依主機或容器的管理方式重新載入；檢查失敗時先還原或修正，不能把另一台機器的語法通過結果當成正式環境已可用。

沒有壓縮或發生錯誤，先找原因

只有小檔案沒有壓縮：先檢查最小大小與內容型別限制。對很小的回應，壓縮額外開銷可能沒有幫助。
圖片或 ZIP 沒有壓縮：已經壓縮的格式通常不適合再用 GZIP。要縮小圖片，處理圖片本身的尺寸與編碼；要縮小上傳 ZIP，整理包內資源。tiiny.host 上傳限制就是檔案大小與傳輸壓縮要分開判斷的例子。
修改後出現 500：先還原剛加入的規則，再查看伺服器錯誤紀錄。可能是語法、指令權限或模組等問題，不能只靠 500 狀態就認定少了 mod_deflate。
出現編碼錯誤或頁面無法顯示：核對實際回應本文與 Content-Encoding 是否一致，以及主機、PHP、代理之間是否重複或錯誤處理。先回復最後一次變更，再逐層定位。
問題出在第三方網域：你的 WordPress 設定通常不能改變第三方伺服器的回應。先確認資源用途，再決定是否聯絡供應商或調整載入方式。

共享主機不開放設定時，把具體網址、回應標頭與資源型別交給客服，比在 wp-config.php 不斷加入壓縮程式碼更容易找對問題。PHP 輸出壓縮也不會自動涵蓋伺服器直接提供的所有 CSS、JavaScript 與圖片。