Run, Run As Fast As You Can

Posted on April 02, 2004  |  

Posted in Design


For the past couple of weeks I've been reading Andrew King's Speed Up Your Site: Web Site Optimization. This is a truly impressive book. It's a collection of very helpful techniques targeted to make your pages smaller, leaner, faster. Almost like the old "Altius, Citious, Fortius" Olympics slogan.

Even though the book contains a wealth of information I think it lacks one key optimization technique: common sense. For example, the author advocates not closing some tags because a browser will do it anyway. The difference between <img> and <img/> is... 1 byte (well, 2 bytes if you speak Unicode)! But this is exactly what we're trying to encourage other developers and designers to un-do and un-learn! I totally agree that shortening a hex color of #336699 to #369 does make it smaller and more readable, but leaving <tbody> open pushes optimization to an insane extreme.

'Speed Up Your Site' by Andy KingOptimization is great. It works. It's worth the time and effort. It should be handled with care, though. Instead of trimming your alt tags to something meaningless start with getting rid of archaic nested tables and font tags and move your presentation into an external CSS. That'll cut page fat right then and there. Next step is to utility optimization techniques Andrew King talks about. Do this with an open mind, though.

One very interesting and helpful technique the book highlights is HTTP compression. Interestingly enough Cost-Effective Website Acceleration got me thinking along the same lines. The idea is pretty simple:

  1. Send as little data as possible
  2. Send it as infrequently as possible

The first goal can be accomplished to a large degree through HTTP compression. The second—with various server and client-side techniques such as reducing the number of postbacks and performing some tasks on the client with the help of JavaScript. You will mostly find mention of Apache modules for HTTP encoding. Therefore I set out on a quest to find a .NET library of the same kind. I found one by Ben Lowery which proved to work great. This very site uses this module and I'm loving it.

What about a performance hit caused by compression? Yes, you somewhat tax the CPU but... What is faster: to compress the page and save time on serving a smaller page, or serve a bigger one which takes longer to download? I conducted some tests in Microsoft Application Center Test and found out that compression allowed us to save tons of bandwidth by streaming less, and service more requests. Network latencies from passing around bigger uncompressed pages offered "sub-optimal" performance. The web application in question manages a lot of dynamic content in real time, and therefore its pages tend to be somewhat big. On average a 70K page compresses easily into 6K or so! HTML is an easy target for compression because it's repetitive. Aaaaah, now you can benefit from all those table tags!

Ironically enough, HTTP encoding has been around for a couple of years and is supported by modern browsers, but you will find few sites that actually utilize it. As a matter of fact, it's incorporated into the HTTP 1.1 standard. I think we can write this off on collective ignorance.

You can give your web app even more boost by configuring IIS for caching but this is a story for another day. I promise a post about it.


on October 12, 2004

Ben Lowrey's site appears to be down, do you have any info on where we can get a look at his http module?

Milan Negovan
on October 12, 2004

Yep, I noticed it recently too. His site says it'll be back up in 27 days from today. :)