開啟靜態檔案 GZIP 壓縮能顯著提升網站載入速度、降低頻寬、改善 SEO (Google 確認速度為排名因子、百度蜘蛛抓取時間固定下速度越快抓取頁面越多)。但 IIS 6 與 IIS 7 的壓縮機制存在關鍵差異，導致相同配置在不同版本表現迥異。本文深度剖析機制差異、根因定位、優化配置方案。

核心差異：執行緒模型與快取策略

特性	IIS 6 (Windows Server 2003)	IIS 7/7.5/8/8.5/10 (Windows Server 2008+)
壓縮執行緒	獨立背景執行緒	主執行緒同步執行
首次請求回應	返回未壓縮版本，背景執行緒開始壓縮	返回未壓縮版本，主執行緒同步壓縮
壓縮版本儲存	長期保存於壓縮快取資料夾 (%windir%\IIS Temporary Compressed Files)	不長期保存檔案，僅記憶體暫存或臨時檔案短暫保留
後續請求	直接從快取資料夾讀取壓縮版本回應	重新評估「是否值得壓縮」
觸發長期快取條件	無條件：一旦壓縮完成即長期快取	頻率閾值機制：frequentHitThreshold + frequentHitTimePeriod

IIS 7 頻率閾值機制詳解

IIS 7 為節省 CPU 壓縮成本，引入「熱門度判定」：只有在 frequentHitTimePeriod 時間窗內，對某靜態檔案的請求次數超過 frequentHitThreshold，才會將壓縮版本長期寫入快取資料夾。

• 預設值：frequentHitThreshold = 2、frequentHitTimePeriod = 10 秒 (官方文檔預設值可能隨版本不同)
• 現象：首次訪問無壓縮 → 短期內再訪問有壓縮 (記憶體暫存) → 幾分鐘後再訪問又無壓縮 (快取被清理、未達閾值不寫入長期快取)
• 若快取資料夾已存在壓縮版本 → 直接返回，不再判斷閾值

兩種讓 IIS 7 像 IIS 6 一樣「無條件長期快取」的配置方案

方案一：web.config 修改 (應用層級，虛擬主機適用)

<configuration>
  <system.webServer>
    <serverRuntime 
      enabled="true" 
      frequentHitThreshold="1" 
      frequentHitTimePeriod="00:10:00" />
  </system.webServer>
</configuration>

含義： 10 分鐘內只要被請求 1 次 即視為熱門，長期快取壓縮版本。virtual host 用戶首選，無需伺服器權限。

方案二：appcmd.exe 命令列修改 (伺服器層級，VPS/獨立伺服器適用)

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/serverRuntime -frequentHitThreshold:1

或同時調整時間窗：-frequentHitTimePeriod:00:10:00

微軟官方建議：

較不激進做法：不降低閾值，改為延長時間窗 (如 frequentHitTimePeriod="01:00:00" 1小時)，平衡效能與資源佔用。

虛擬主機用戶的無奈與建議

虛擬主機通常無法修改 serverRuntime 區段 (被主機商鎖定)。建議：

1. 提交工單要求主機商調整或開放權限
2. 選擇支援 .NET Core/ASP.NET Core 的現代主機 (Kestrel + IIS 模組架構壓縮邏輯不同)
3. CDN 層面啟用壓縮 (Cloudflare、又拍雲、七牛雲等)，繞過源站 IIS 限制
4. 應用層自行壓縮 (ActionFilter/中介軟體攔截回應流 GZIP)，但失去 IIS 原生效能優勢

---

總結： IIS 7+ 為了伺服器整體效能犧牲了單一站點的「無條件壓縮快取」。理解 frequentHitThreshold / frequentHitTimePeriod 機制，根據擁有權限層級選擇 web.config 或 appcmd 調整，或轉向 CDN/應用層壓縮，是解決靜態檔案壓縮不穩定的關鍵。