同一個 app.js，檔案內容沒變，Network 顯示的下載容量卻不同，不一定是模板漏載入。瀏覽器收到的資料可以先壓縮，再解壓成原本的 JavaScript。要比較大小，先分清「傳輸中的回應內容」與「解壓後的檔案」。
312 bytes 和 1,371 bytes，哪個才是真的？
用一份載入 20 個範例項目的 JS 比較兩種回應：未壓縮原文是 1,371 bytes；gzip 回應的原始內容是 312 bytes，解壓後仍是 1,371 bytes，內容逐位元組相同。瀏覽器收到 gzip 版本後，頁面照樣顯示 20 個項目。
| 回應方式 | 回應內容容量 | 解壓後內容 |
|---|---|---|
| 未壓縮 | 1,371 bytes | 1,371 bytes |
| gzip | 312 bytes | 1,371 bytes |
這只是這份範例的數字，檔案內容與壓縮設定不同，結果也會不同。HTTP 標頭、連線成本並不包含在表中的回應內容容量裡；它不能直接換算成整站加速比例。
先讀這三個標頭
在 DevTools 的 Network 點選 JS：請求的 Accept-Encoding 表示客戶端能接受哪些編碼；回應的 Content-Encoding: gzip 才表示這筆內容使用了 gzip。有列在請求裡，不等於伺服器一定選用。
如果回應帶有 Content-Length，搭配 gzip 時，它描述的是編碼後的內容長度。工具可能另顯示解壓後大小，下載工具也可能自動解壓；不要拿不同口徑的兩個數字，判斷哪個檔案有缺漏。
同一網址依 Accept-Encoding 提供不同版本時，回應的 Vary: Accept-Encoding 可讓快取按這個請求標頭區分版本。它是快取選擇條件，不是「已啟用 CDN 加速」的證明。
確認功能正常，再談壓縮設定
查清回應狀態、標頭與實際內容，再看頁面功能：JS 是否執行、選單或列表是否正常。要比原始傳輸內容，先確認取樣工具沒有自動解壓；要比程式內容，則把 gzip 解壓後再和未壓縮版本比對。
不用把已壓縮的圖片、ZIP 再強行套 gzip；重複壓縮可能沒好處，甚至更大。這個檢查方法也不代表來源伺服器或 CDN 設定需要更改。真的要調整，先在自己的測試環境保存設定與回滾方式，核功能後再決定，不為追求小數字直接改正式站。
參考資料
資料核對：2026年10月4日。文件與網站環境可能更新，操作前請核對自己的設定。
評論0