Enabling IIS 6 native HTTP compression for PHP
For decades Windows has marketed its graphical based user interfaces, and this in turn seems to have nurtured a mindset amongst the majority of Microsoft users that if it isn't in the graphical user interface then it isn't there. This is true to an extent for the standard end user as the graphical user interfaces are only generally designed to cater for the most used functions. However for system administrators and engineers working with server related technology this mindset will result in them only ever seeing the tip of the iceberg of what the technology can actually achieve for them. HTTP compression in IIS 6 is one of these items that is hidden under the hood, and can only be extracted by venturing further into IIS than what the graphical user interface can offer. Is it worth it? Well if saving 75% or more off your bandwidth bill, and delivering significant performance improvements for your clients in terms of website loading times is of interest to you, I suggest you read on and in just ten minutes from now you'll be wondering why you never looked into HTTP compression before.
The reason I am witting this article is that so often I see new budding webmasters putting their heart and soul into the visual presentation and content of their website, only to completely neglect the fundamentals of how that content is going to be delivered to their visitors. What they end up with is a great looking website with some good content that is severely stunted growth wise because the amount of data transfer required to get the website contents to their visitors.
In this article we will look at how to enable the brilliant HTTP compression built right into IIS 6 specifically for PHP based websites such as Xoops. Compression upwards of 75% is not uncommon, but the overall advantage this has for your website totally depends on the amount of compressible content contained in your site. So if your site is mostly text based with little use of image graphics, then you stand to make massive performance gains through HTTP compression. On the other hand if your site contains little text and is heavily graphics based, then HTTP compression will not deliver significant performance gains for you.
How does compression effect search engine spiders and proxy servers?
Since publishing this article the question of how compatible IIS 6 native compression is with search engines and proxy servers has been asked a few times. Search engines should not be effected as when a client sends a request IIS analyzes the headers to see if the client is compression enabled. This is usually done by using the Accept-Encoding: gzip, deflate header. If the client is not determined to be compression enabled, then they are not sent any compressed content. This is true for search engine spiders and standard web browsers. I have been using HTTP compression on several sites for a very long time, and it has not effected their ranking or ability to be crawled by search engine spiders at all.
As for proxy servers, by default IIS marks the expiration date of all compressed data to Janurary the 1st 1997. This is so that proxies do not serve cached copies of compressed data to browsers that do not support compression. The default settings for the HcExpiresHeader, HcCacheControlHeader, and HcSendCacheHeaders metabase properties in IIS 6 are set so that older clients and proxy servers do not attempt to cache compressed files. Even if you do have some proxies that do not handle caching of compressed items properly (even those that advertise themselves as being HTTP 1.1.
ENABLING IIS 6 NATIVE HTTP COMPRESSION
As much of a fan I am of the compression in IIS 6, I am not a great fan of the process required to get it set up. User friendly it is not, and requires you to set several options in the IIS Admin control panel MMC, as well as a new web extension, and finally requires some editing of the IIS 6 metabase. Anyway, lets get on with it. For this guide I will be using my beta site which is an exact copy of the site you are on now.
The uncompressed website
Lets start at the beginning (always a good spot) and see what our sites compressible content looks like before any compression takes place. To do this I will use the online compression checking tool at Port80Software where you can enter your URL and it will scan your site for compressible content. What is returned is an estimate of what you stand to gain through HTTP compression. Usually it is pretty accurate too.
In figure 1 above we can see that we have 30365 bytes of compressible content on my beta site, and it is estimated that we can compress this content by 74% to just 8046 bytes. I'm sure you'll agree that this is pretty impressive, and it should now start setting off light bulbs in your head as to how this will translate to both money in your pocket through savings in bandwidth usage as well as a better end user experience through faster site performance due to less content being transmitted in order to deliver your site.
Backing up the IIS metabase
The first step before implementing anything like this is to ensure that you take the steps necessary so that you are able to restore your environment in the event that something goes wrong. For IIS this is a very simple task, and all you have to do is follow my guide on how to backup your IIS 6 metabase .