The Tests
To test this software to the extreme, we made a test plan.
We installed httpZip first on our development server, where a copy of the
production sites runs, so we could first test its functionality. Then as a
second stage, when the above test was completed, we installed httpZip
on one of our production sites.
For this purpose we choose www.FlashFreaks.nl
- which was really a bandwidth eater! Even though FlashFreaks is for the Dutch-only
fans of Macromedia Flash (and
considering that Holland is not that big country) - this site receives a HUGE
amount of visitors. FlashFreaks gets about 10,000 unique visitors daily resulting
in more then 3 million page views a month! Only our DMXzone.com is bigger then that. So FlashFreaks eats about
100GB bandwidth per month.
The first test
The installation on our development server went very smoothly.
It restarted IIS after it was done, and took a second to install.
For this test, we didn't change any options - we just called
our website and at first we couldn't really see that anything had changed.
This is how it should be - everything should run fully transparently to the
user, but still we needed a way to verify that it was doing its job correctly!
This is where the extensive httpZip reporting kicks in.
You can call the httpZip reporting by adding the /httpZipreport/report.htm
next to your site name in your browser. On the report page you can easily
see the achieved compression. There are general statistics which show directly
the bandwidth savings due to the compression - you can even see how by much
individual files get compressed on your site. .
In our test, the ASP files we use produced about 70-80%
compression! That's a nice level of reduction, but using some of the extra
features of httpZip you can get even more. Let's look at some of the other
cool things that are switched off by default.
White space Removal
This is one of the options that is
switched off by default - as you definitely do not want to have it
for example when you are developing your website, because you need readable
html.
However when you are running production - you don't really
care about html indenting, so why not remove all the white space?
This is exactly what this option does - you can even compress
CSS tags as well. Also it can convert all the html tags to lower case so that
even better compression can be achieved - and, if you're not using deprecated
tags, it has the side-effect of making them XHTML-compatible.
So when we switched this option on - with all its power
- we were able to get compression of 80-90%. Now that's a bandwidth
squasher!
By viewing the source in your browser, you can see that
it is being compressed.
After setting this option on, we ran some more tests to
see if our site was still functioning completely.
A small glitch
We discovered that the site was fully functional and everything
was running great! However there was a small glitch with some special inline
JavaScript code for an event on an html tag - but when we reported that to
port80software they had a new version just within a few days which ran perfectly
without any problems.
You need reactive support on products that change your source,
of course, in case anything goes wrong.
Of course it is best to test this white space removal option
on a test server first - so you know that your site is running well before
going live on the production server.
Also there is another great tool by port80software called
w3compiler which performs client side optimizations so you can do your white
space compression in front! In the upcoming w3compiler - developers can optimize
their pages before they put them on the server, thus saving runtime CPU and
saving more time.
Browser support
Additionally we did some tests with different browsers:
all versions of IE , Netscape 4 to 7, on PC and Mac,
Opera browsers on PC and Mac, Safari on the Mac - and every browser decompressed the source without a problem. Realistically,
all the popular browsers can support http compression.
The proxy issue
The only one issue we found was that if we use a browser
behind a corporate proxy - the pages we got weren't getting compressed. The
weird thing was that only IE had this behaviour. After some investigation
and discussion with port80software, we found out that only pages called HTTP
1.1 are getting compressed. It turns out that IE was using default HTTP 1.0
when it connects though a proxy!
This is easily solved by changing the options in IE to use
HTTP 1.1 even if it goes though a proxy. Of course, requiring home users to
change advanced options isn't really the way to go, but then most home users
aren't behind a proxy server anyway.
