Run, Run As Fast As You Can
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/> 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
#369 does make it smaller and more readable, but leaving
<tbody> open pushes optimization to an insane extreme.
Optimization 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:
- Send as little data as possible
- Send it as infrequently as possible
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.