Click here to gain a huge performance boost!

If you are working in the IT business, you probably know that performance is a feature. Doesn't matter whether you are optimizing indices as a DBA, dealing with some hidden settings close to the bare metal as web master, motivating your team as team leader, or hacking directly into your IDE as a developer - most likely you are concerned about performance of your application this way or the other.

Gain a huge performance boost within one hour? Sounds a little bit like spam, I know, but still I want to urge you to read on - net improvements of bandwidth consumption of 60 - 70% are really quite possible!

For web applications, Yahoo prepared a list of best practices for speeding up your web site. They even provided an easy-to-use browser plug-in called YSlow which tells you immediately how your webpage performs against their metrics. Unfortunately, not all of these tips apply for you if you are not running a web site the size of Yahoo. Furthermore, these changes need to be planned well ahead and might require significant changes to your overall architecture. Thus, implementing them might be quite costly a task.

But hold on, did I say all of these? Far from it! There is one, in the best practices document referred to as "Gzip components" (or here, further on HTTP Compression), which comes essentially for free! Now, admittedly, this is not at all a new approach. HTTP Compression is fairly well supported since IIS 6.0, and already in 2004, Jeff Atwood described using it as a "no-brainer".

Probably you and your company are using this functionality already, in which case I still ask you to double-check whether your content is received gzip'ed on the client. Browser add-ons like Firebug or stand-alone tools like Fiddler allow you to inspect the content of HTTP requests and responses and to look for the magical "Content-Encoding: gzip", which indicates that the compression is fully operational.

Odds are, that even tough you and your colleagues know about HTTP Compression, it become that normal and commonly used these days that you don't even make sure any more whether it's actually in place and received on the clients as expected.
However, there are several things which might go wrong - for instance, IIS 7 has a default setting which prevents HTTP compression in case the request came via a proxy (noCompressionForProxies, which defaults to true) ... So take the time and check on an actual client browser!

If you have not heard about it at all up to now, take the time. I'm really convinced that this has pretty much the highest return-on-investment ever.

For those of you residing within the Microsoft eco system, you might consider the following hints useful.

IIS 6.0

A nice description about setting up HTTP Compression is found here. There is an official guide from Microsoft as well, but don't trust it, as it misses a few very important steps (especially when it comes to 'making your hands dirty' in the config files yourself). 

IIS 7.x

Should be much easier than in IIS 6.0. I found a nice manual which covers all steps necessary. One setting that was very important from within the organization I'm currently working for is:

noCompressionForHttp10="false" noCompressionForProxies="false"

Check the configuration reference for further details.

For troubleshooting, these links might help you:

http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis/

http://www.iis.net/ConfigReference/system.webServer/tracing/traceFailedRequests

So, either you were fully using HTTP Compression already, in which case you probably did not read until here anyway ... or otherwise, take the time, surprise your colleagues with your great performance boost and make a day off the other day ... no need to thank me, I'll take a beer instead :-)