網站載入速度快慢，歸根結柢是下載資料的大小與傳輸時間。無論主機規格再好、CDN 再快，如果每次訪客進站都要搬一堆未壓縮的 HTML、CSS、JavaScript，就像用吸管喝果汁一樣——吸力夠大、果汁夠濃，但單位時間的流量就是卡住了。Gzip 與 Brotli 伺服器端壓縮正是解決這個問題的根本方案，能把文件大小瞬間砍掉 60～80%，幾乎是建站最 CP 值最高的優化。
伺服器壓縮與前端 Minify 的差異
許多站長容易把伺服器壓縮與 CSS/JavaScript 壓縮（Minify）混為一談，兩者概念相反。Minify 是前端優化，把原始碼裡多餘的空格、註解、換行刪掉，工作發生在上線前——CSS 檔案從 50KB 砍到 35KB。伺服器壓縮是傳輸層優化，訪客按下瀏覽器 refresh 時才啟動——主機先把回應的 HTML、CSS、JS、JSON 即時打包成 .gz 或 .br 格式，傳給瀏覽器，瀏覽器再自動解壓並呈現。
換句話說，Minify 減少原始檔案本身的體積；伺服器端壓縮在保留原始檔案的前提下，臨時壓縮傳輸內容。這兩個優化層互不抵觸，反而應該同時做——前端先 Minify，傳輸層再 Gzip，效果才能最大化。
實際效果是什麼樣子？以 WordPress 首頁為例。未啟用伺服器壓縮時，傳輸大小約 200KB；啟用 Gzip 後，同一頁面的傳輸大小可能只剩 40～60KB，頁面載入時間直接少一半。Brotli（Google 開發的現代壓縮演算法）壓縮率還能再好 10～20%，但支援度不如 Gzip 廣，所以實務上通常 Gzip 和 Brotli 並存，讓瀏覽器自動選擇支援的版本。
確認主機是否已啟用伺服器壓縮
在動手設定前，先用一個簡單方法看自己的主機有沒有活著。最直接的方式是用 GTmetrix 或 PageSpeed Insights 的「Network」頁籤。開啟你的網址，切到 Network，找任何一個 .js 或 .css 檔案，點開查看 Response Headers 欄位——如果看到 Content-Encoding: gzip 或 Content-Encoding: br，表示已經開著。如果什麼都沒看到，就是還沒啟用。
另一個方法是用線上工具 httpbin.org 的 /gzip 端點，或直接用瀏覽器開發者工具。Chrome 開啟網頁 → F12 → Network → 任選一個請求 → 檢查 Response Headers 的 Content-Encoding 欄。
如果確認沒有伺服器壓縮，接下來就看主機類型。大多數現代主機商（Cloudways、Kinsta 等託管方案）預設就開著，不用手動設定。但傳統 cPanel 主機或自架 VPS 的使用者，通常需要自己動手——或者透過快取外掛的自帶功能偷懶。
Apache 伺服器用 .htaccess 手動啟用
如果你的主機用 Apache，最簡單的方法是編輯根目錄下的 .htaccess 檔案。如果檔案不存在就新建一個，放以下程式碼：
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/json
AddEncoding gzip .gz
<IfModule mod_setenvif.c>
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|svg)$ no-gzip
</IfModule>
</IfModule>
這段代碼的意思是：啟用 mod_deflate 模組（Apache 的壓縮核心），對 HTML、CSS、JavaScript、JSON 這些文字型文件自動 Gzip。圖片、影片等二進位檔案被排除——它們本身已經是壓縮格式，再壓一次也沒用，還會浪費 CPU。
設定好後，存檔並上傳回根目錄（通常是 public_html 或 www）。WordPress 預設的 .htaccess 已經有 rewrite 規則在裡面，直接把上面的 IfModule 區塊貼進去就行，不要覆蓋既有內容。上傳後等個 5 分鐘，用 GTmetrix 或開發者工具重新檢查，應該會看到 Content-Encoding 欄位出現 gzip。
Nginx 伺服器設定
Nginx 沒有 .htaccess，所有設定都在 nginx.conf。如果你用的是標準 Nginx VPS 或 Cloudways 平台，可能沒有直接編輯 nginx.conf 的權限（由廠商統一管理），此時該看廠商的控制面板有沒有提供一鍵開啟選項。Cloudways 例如就有「Gzip Compression」開關，按一下就完成。
如果有後台權限自己改 nginx.conf，可以在 http 或 server 區塊裡加入：
gzip on;
gzip_vary on;
gzip_types text/html text/plain text/xml text/css text/javascript application/javascript application/json;
gzip_disable "msie6";
gzip_comp_level 6;
gzip on 代表啟用，gzip_comp_level 6 是壓縮等級（1～9，6 是效能與壓縮率的平衡點）。改完後記得重啟 Nginx 服務才能生效，通常是 sudo systemctl restart nginx 或 sudo service nginx restart。
快取外掛提供的替代方案
如果你不想碰 .htaccess 或 nginx.conf，快取外掛通常也有內建的伺服器壓縮功能。像是 WP Rocket、LiteSpeed Cache、W3 Total Cache 都能在後台一鍵啟用。以 WP Rocket 為例，進後台 → WP Rocket 設定 → 檔案最佳化分頁 → 勾選「啟用 Gzip 壓縮」，儲存即可。
不過要注意一點：快取外掛做的壓縮有時是「應用層」模擬（用 PHP 產生 .gz 檔案），而不是真正的伺服器 mod_deflate。前者效果沒有伺服器原生那麼好，尤其是動態內容多的網站。所以最理想的方案還是讓伺服器層面本身就啟動，外掛壓縮改只在伺服器沒啟用時當備胎。
許多站長同時裝了快取外掛和伺服器壓縮，結果兩邊衝突——訪客看到某些資源被重複壓縮或根本沒被壓，反而更慢。檢查的方法就是回到前面提的 GTmetrix 或開發者工具 Network，看 Content-Encoding 欄位。如果同一個檔案出現多個壓縮標籤，就是衝突了，需要停用其中一邊。
測試與驗收清單
啟用伺服器壓縮後，用幾個工具確認設定有無成功。第一是用 Google PageSpeed Insights 開你的網站，看報告裡「未使用較小的圖片版本」與「停用未使用的 CSS」之類的條目能否改善。如果壓縮有效，TTFB（Time to First Byte）應該會降低，LCP 可能也會向下浮動。
第二是用 GTmetrix 的瀑布圖（Waterfall）。檢查靜態資源（.js、.css）的 Response Headers，確認都有 Content-Encoding: gzip 或 Content-Encoding: br。如果某些檔案沒有壓縮標記，有可能是快取外掛設定還不完整、或該檔案類型被排除清單擋住。
第三是用線上工具如 www.gzip.wizardzines.com 輸入你的網址，它會直接秀出傳輸前後的體積對比，讓你一眼看清楚省了多少流量。
啟用伺服器壓縮屬於「安裝完就健忘」的設定——開著之後幾乎沒有維護成本，CPU 開銷也很低（通常不到 1%）。除非你的主機是老舊到不支援 mod_deflate 的骨董機器，否則大機率不會有副作用。許多新手以為 WordPress 效能優化得靠一堆複雜的 PHP 調校或動輒數千元的高階主機方案。其實最快的回報來自這些「一次設好就受用終身」的基礎設定——伺服器壓縮、快取外掛、CDN 三樣齊全，網站速度就能達到大多數讀者滿意的水準。