前陣子有人問說 IIS7 靜態內容壓縮為何無法運作，當我抽空研究之後發現一些有趣的現象，在 IIS7 的靜態內容壓縮功能在第一次透過瀏覽器下載網頁時並不會進行壓縮，而是要有第二次 HTTP Request 時才會對該內容進行壓縮，而這個時候才會真的耗用 CPU 資源進行檔案壓縮，壓縮完之後才會將壓縮內容回應到用戶端。
IIS7 靜態內容壓縮大致上可用以下 3 個步驟說明：
1. 使用者透過瀏覽器連接 IIS7 網站，網址為：http://example.com/test6.txt，由於是第一次下載靜態內容，所以 IIS7 並不會壓縮該檔案，下載速度也很快（不考慮頻寬因素），網頁的下載時間為 15.64ms 網頁大小為 29KB（如下圖示）
2. 然後我們在網頁按下 F5 重新整理網頁，這次是第二次下載靜態內容，網頁的大小為 1.9KB，這代表網頁已經被壓縮過再回傳，檔案小了 14 倍之多，但因為需要對該檔案進行壓縮動作，需要耗用到 CPU 資源，所以網頁下載時間變長了，總共花了 1032.46ms 時間。
這時壓縮過的網頁會在預設的 C:\inetpub\temp\IIS Temporary Compressed Files 靜態內容壓縮快取目錄出現一個相同檔名的目錄。
該檔案會是壓縮過的版本，如果用 Notepad 開啟該檔會發現是亂碼，其實這是壓縮過後的文字檔罷了：
如果你將該檔案副檔名加上 .gz 並用 7-zip 解壓縮軟體開啟，就可以發現該檔案未壓縮時的大小，也可以解壓縮出來看內容。
3. 我們第三次下載靜態內容，得到的結果就會得到非常驚人的結果，首先網頁內容變小了，跟第二次下載的內容一樣，不過下載時間總共花了 0ms 時間，你沒看錯！Fiddler 偵測不出有任何時間差異，所以該網頁下載時間為 0，這是因為我在內網測試的關係，所以才會這麼快。
透過這個基本的圖解與測試，相信可以讓你更清楚知道 IIS7 靜態內容壓縮的細部過程。
相關連結