互聯網信息服務（IIS）的每個後續版本都會引入更多的選項來控制輸出的緩存和壓縮。比如，IIS 7.0首次安裝時會默認啟用壓縮靜態文件，而禁用動態產生的文件壓縮功能，尤其是.ASP或者.ASPX網頁。 因此，這個功能必須在IIS 7.0中手動啟用，因為壓縮動態產生的內容可能會出現幾個問題。由於IIS 7.0的某些變化，靜態內容現在是默認壓縮的，這讓處理器的壓縮效率更高。 使用動態壓縮時，可以設置的選項之一是一個叫做緩存前動態壓縮的ASP.NET應用程序指令，它是urlCompression元素的一部分。請注意，你也可以通過urlCompression來設定靜態和動態壓縮，但是絕大多數時間你只能通過應用程序的IIS控制面板來設定。 所以緩存前動態壓縮選項（或者簡稱BeforeCache）描述了IIS如何壓縮並緩存動態生成內容。當把這個選項的值設成TRUE時，內容會被生成、壓縮、添加到一個緩存，然後按順序從該緩存輸出到客戶端。當把值設成FALSE時，生成的內容格式不是壓縮的，得到請求之後再重新壓縮。 把BeforeCache設成TRUE似乎是一個好主意。如果你需要壓縮許多相同的動態生成內容，把它們提前壓縮一次然後再多次使用還是有意義的。你會節省大量的帶寬以及大量的CPU周期。不過，在有些情況下BeforeCache不會起作用，應該加以說明。 首先，根據微軟對BeforeCache的評論，“當輸出緩存響應刷新後，在該響應進入輸出緩存之前動態壓縮不會執行。”這就意味著那些擁有專用輸出緩存處理方式的網站在使用BeforeCache時可能會出現問題，比如說提供過時內容、或者給一個用戶提供其他用戶的定制內容等。 另一件需要注意的事情是：不同類型的壓縮形式對緩存功能會有什麼樣的影響。IIS 7.0支持GNU壓縮和deflate壓縮，它們是兩種常用的網絡客戶端壓縮類型。此外，他們現在的運行更可靠，在IIS5.0中，壓縮活動明顯失敗。當一個客戶端沒有明確指定它可以接受什麼代碼時，或者當你的應用程序不能處理不同編碼的頁面請求時，事情會變的很復雜。 最後，網頁不會自動緩存。相反，對於那些頻繁請求的內容，IIS會進行自動緩存。默認情況下，10秒鐘內請求兩次或者兩次以上的網頁都屬於這種類型，就像frequentHitThreshold 和 frequentHitTimePeriod服務器參數控制的那樣。如果一個網頁每隔五分鐘才請求一次，那麼它將不會被自動緩存。如果人們正在一個系統上測試緩存功能，但是開始的時候他們沒有生成合適的負載來激發緩存。
