I have a number of ASP.NET MVC websites on a windows 2003 box which runs IIS6.

Will enabling IIS6 compression make any difference with regards to performance?



  • What aspect of "performance" are you interested in? – Shane Madden Aug 30 '11 at 15:09
  • With regard to enabling G-Zip to reduce the response time of the HTTP response for .aspx and .ascx files. – dagda1 Aug 30 '11 at 15:59
  • Compression acts after a page is generated and the content is being sent to the client; it has no impact on the time taken to generate a response. – Shane Madden Aug 30 '11 at 16:16
  • @dagda, Shane is 100% correct. Compression does not affect the amount of time taken to generate a page. It lengthens the time for the server to respond as it has to generate and compress the page. Transmission time will be minimized, which is commonly very little with today's high speed connections. When the server is heavily loaded the compression time may quickly become the dominant factor in response time, it will depend on many factors you haven't provided. "Performance" is a pretty meaningless word. – Chris S Aug 31 '11 at 14:22

Static compression is a one-time hit and then gets cached for future use. So it's rarely a problem.

But as you have an MVC site, you'll have to use dynamic compression too. That does take a CPU hit on each request, though it usually is worth the cost. Most of the time, there are extra CPU cycles to spare but limited bandwidth on your client. So more often than not compression is a good idea. But if the server spends most of its time at a certain high load, whether or not it is helping or hurting varies.

You can adjust the level of compression to fit your needs, which is advisable as each general usage scenario varies per site, server, and bandwidth. See IIS Compression in IIS6.0 or IIS 7 Compression. Good? Bad? How much? (which is about IIS7, technically, but the discussion on limits is more thorough).

(I forget if IIS6 does this, but be aware that IIS7 will shut dynamic compression down when the server reaches a certain load and doesn't turn it back on until it drops to a much lower load. I can't find the reference for this info right now though--so don't take this as gospel.)

I would say that 99% of the time, turning on compression is a good thing. But as with any performance tweak, make sure you test and adjust to fit your needs specifically.


If you are delivering/downloading large amounts of textual data in the application, it is very easy for the developer to enable Gzip/Deflate in code, and that works independent of IIS. In that case, it may already be enabled, but you may not be aware of it.

Here is a relevant excerpt from the Pro ASP.Net MVC book by Steven Sanderson:

"Don’t forget that HTTP compression is only really useful for textual data. Binary data, such as graphics, is usually already compressed. You will not benefit by wrapping gzip compression around existing JPEG compression; you will just burn CPU cycles for nothing.

"Note: IIS 6 and later can be configured to compress HTTP responses, either for static content (i.e., files served directly from disk) or for dynamic content (e.g., the output from your ASP.NET MVC application). Unfortunately, it’s quite difficult to configure (on IIS 6, you have to edit the metabase directly, which might not be an option in some deployment scenarios), and of course it doesn’t give you the fidelity of enabling or disabling it for individual action methods. "

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.