先釐清效能問題
網頁慢不一定是壓縮問題。對香港中小企而言，真正要問的是：伺服器有否有效率地把可壓縮的文字資源送到顧客使用的瀏覽器，同時保持內容及快取正確。HTML、CSS、JavaScript，以及不少文字型 API 回應都有重複字串，通常可以縮小；JPEG 圖片、影片及 ZIP 檔案本身已經編碼，再壓縮未必有益，甚至可能變大。更改設定前，先盤點實際重要路徑，包括首頁、商品或服務頁、結帳步驟，以及它們載入的腳本和樣式。記錄回應類型、可取得時的原始大小、傳輸大小及現有內容編碼。這些是自己網站的基線觀察，不是指南所保證的效能數字。
HTTP 壓縮針對網絡傳送的內容表示形式。它不能移除沒有使用的 JavaScript、縮小過大的照片、修好緩慢的資料庫查詢，也不能保證頁面載入後的每次互動都更快。對網絡受限的首次訪客而言，傳輸改善仍可能有價值。應把這個決定與其他效能工作分開，避免把傳輸量下降誤說成所有體驗指標都改善。負責人可在相同網絡條件下比較更改前後的同一組頁面，但亦應親自打開頁面並完成實際任務。最後要判斷的是傳輸內容是否正確、協商是否可靠，以及縮小體積是否值得伺服器付出運算，而非儀表板上有沒有「已壓縮」標誌。
了解瀏覽器與伺服器如何協商
瀏覽器在要求標頭 Accept-Encoding 宣告自己能處理的編碼。伺服器可選擇支援的方式，例如 gzip 或 br，並在回應標頭 Content-Encoding 寫出實際使用的方式。若送出未壓縮內容，就不能錯誤標成 gzip。HTTP 規範定義了這些欄位，MDN 的壓縮指引亦解釋常見協商流程。瀏覽器支援 Brotli，不代表每個回應都必須使用 Brotli；資源類型、伺服器設定和運算成本都可能影響選擇。瀏覽器標頭是能力宣告，不是要求每個位元組都要壓縮的命令。應測試只接受 gzip 的用戶端、同時接受 br 與 gzip 的用戶端，以及在支援情況下需要未壓縮回應的要求。
快取系統需要足夠資料把不同編碼版本分開。若回應會因 Accept-Encoding 而改變，就要提供合適的 Vary: Accept-Encoding 回應欄位，否則中介快取可能把壓縮內容送給不能解碼的用戶端，或錯配版本。有 Content-Length 時，它描述的是已編碼傳輸內容；直接拿它與磁碟上的原始檔案大小比較，容易誤解。瀏覽器開發工具通常分別顯示傳輸大小與解碼後資源大小，報告時應清楚標示。Content-Encoding 亦不同於 Transfer-Encoding；後者處理訊息在某一傳輸環節如何送達。分清這些概念，才不會為解決壓縮設定而誤改無關的分段傳輸行為。
按資源與風險設定
可先從足夠大的文字回應入手，並確認網站已使用 HTTPS。若實際內容有可壓縮文字，HTML、CSS、JavaScript、JSON 和 SVG 都可能適合。要查伺服器的內容類型規則：靜態檔案已正確壓縮，不代表動態 HTML 也有處理，反過來亦然。不要盲目重壓已壓縮的媒體。極短回應可能因標頭與運算開銷而得益很少，應量度實際結果，不宜在所有資源套用同一級別。若 CDN 或反向代理亦負責壓縮，須界定哪一層作準，並檢查顧客在公開邊緣取得的最終回應。重複壓縮，或標頭只描述兩層中的一層，都可能令解碼失敗。設定必須以顧客真正到達的部署路徑為準。
對同時包含可由外部操控文字與秘密資料的回應要更審慎。在某些設計中，觀察者若可反覆影響部分內容並量度壓縮後大小，可能推知資訊。不必因此把所有公開樣式檔的壓縮都關掉；應單獨辨識敏感頁面及評估其風險模型。也要檢查代理改寫內容表示形式時如何處理 ETag 等驗證標記，以及大型資源是否涉及範圍要求。這些都說明不能只複製通用伺服器設定片段，而要測完整傳遞鏈。為壓縮規則保留可回復的開關，記下涵蓋的路徑及內容類型。若某類資源有問題，業務應能只撤回該類設定，而不用捨棄其他已正常運作的改善。
以小網站作一次驗收演練
設想一間服務公司有資訊頁、預約頁和可下載小冊子。團隊懷疑 HTML 與 CSS 未壓縮。首先從公開網域保存兩種頁面及主要 CSS 檔的回應標頭與傳輸大小；小冊子 PDF 也一併記錄，但不預設它會因此受益。之後在選定的邊緣層為合適文字啟用壓縮，並以受控的 Accept-Encoding 值重做要求。對每項文字回應，檢查內容能否解碼、Content-Type 是否維持正確、Content-Encoding 是否與實際位元組一致，以及版本不同時 Vary 是否包含 Accept-Encoding。這些是假設性的驗收步驟，並不是任何 Astera 客戶的實測數據。
接着團隊用一般瀏覽器打開頁面，完成一次預約測試，確認腳本能執行、樣式正常、文字可讀，且沒有解碼錯誤。測試要經 CDN 的公開主機名稱重做，因為在原站本機成功，不能證明顧客取得的回應正確。比較前後時，須分開記錄傳輸位元組與解碼後位元組，並保持路徑、瀏覽器及快取狀態一致。若預約頁 HTML 雖縮小卻仍然很慢，就應調查其他原因，而不能聲稱壓縮已解決整段流程。若回應標頭與實際編碼不符，應立即回復該路徑設定，再修正邊緣規則。傳輸和顧客任務都通過，測試才算完成。
網站變動後仍要維持正確
網站更新可能悄悄改變壓縮覆蓋範圍。新版前端可能新增規則沒有涵蓋的內容類型；新 CDN 路徑可能繞過舊設定；供應商也可能把文字端點改成預先壓縮檔案。可在發佈例行程序中加入小型檢查，抽樣公開資源，查看 Accept-Encoding、Content-Encoding 及 Vary，並確認瀏覽器能解碼每份內容。這比只檢查設定旗標已開啟更有意義。報告數據時，要列明受測資源及期間，把傳輸大小變化與整頁或顧客體驗結果分開。不能以一次抽樣推論所有顧客、網絡與裝置都得到同樣改善。
網站負責人應保留簡短紀錄：哪一層負責壓縮、哪些內容類型合資格、有哪些例外、如何回復設定。若顧客在更新後看到空白頁，客服需要途徑分辨瀏覽器收到不能解碼的內容、腳本出錯，還是其他應用程式故障。改動大範圍設定前，應把失敗回應的標頭及內容與已知正常資源比較。每當主機、CDN 或框架行為變動，也應重看設定。理想結果其實具體而有限：合適的文字使用用戶端可處理的編碼傳輸，快取把不同版本分開，已壓縮檔案得到合理處理，而顧客仍能完成原本想做的事。
進行前先確認
- 有否在公開邊緣測試具代表性的 HTML、CSS、JavaScript 及 API 回應？
- 每個回應的 Content-Encoding 是否為用戶端支援，Vary 又是否合適？
- 更改後顧客是否仍可開啟頁面並完成相關任務？
