Book review of "Speed Up Your Site" by Andy King (free)

Did you know that, for the majority of users, the average site feels twice as slow as it did seven years ago? Neither did I, and it's just one of the eye-opening statistics quoted in " Speed Up your Site" by Andy King. In this review, Bruce Lawson goes through the book and examines its usefulness, and shares some of the many real-world tips from this ruthlessly practical book.

Click here for more details on the book.

When the author first wrote to us and asked if we'd review his book, I was tempted to say no. I mean, how boring can the subject be, especially when spread over 500 pages - and how difficult can it be? Everyone knows that you should (1) choose carefully whether to use gifs or jpegs, and compress them well, (2) use valid html 4.01 or xhtml and have a doctype. That's it, right?

Wrong. King's book is packed with clever ways to speed up the site, and although it's often very dense, it never gets boring. There is a companion web site to the book which, unlike many other sites that accompany books, is not crap.  It actually contains useful information and applications like King's web optimiser utility that we've showcased before on DMXzone http://www.websiteoptimization.com/services/analyze/

Anyway, on to the book, chapter by chapter:

1: The Psychology of performance

2: Flow In Web Design

A common fault with many computer books is to spend a lot of time persuading the person who's bought the book why they need to buy it - kind of like preaching to the choir. It's a fair bet that if you've spent $40 on a book about speeding up your site, you're convinced of the need to do it. It's also, unfortunately, not a particularly friendly nor representative chapter; the rest of the book is ruthlessly practical - getting down to the real nitty-gritty of optimisation, but these chapters dive straight into the fuzzy, subjective world of psychology and perception.

The take-home from these chapters for me was that perceived speed matters more than real speed - e.g., if you give users something useful to look at after 5 seconds while the rest of the site takes another 10 seconds to load (=15 seconds total), it will feel faster than a site that is blank in a browser window for 10 seconds before appearing fully. I suspect that most of us know this already - and, anyway, King doesn't tell us how to achieve this yet anyway. Personally, I skipped though these two short chapters, content with the one page summary on page 25 rather than read how the scientists had reached these conclusions.

3: HTML Optimisation

King points out that, even in the USA, most people don't have broadband, and although most home users have doubled their bandwidth from 28 to 56Kbps, the average web page has increased from 8K to 28K since 1996 - so pages will feel almost twice as slow to a dial-up user as they did 7 years ago. The worst bottleneck on the web is bandwidth. For example, downloading the new Mozilla over broadband took much longer than unzipping, decompressing and installing it on my wife's 2 year old RAM-challenged PC.

One of the top techniques for optimising your site is to squirt it down the line as fast as possible: optimise your HTML, anything to push as few bytes to the user as possible. But can anything be done to make HTML optimised - after all, it's just tags and text isn't it?

Wrong. Most HTML that you get sent is largely white-space (25- 30% on average), comments and other stuff that makes the user's download longer (and their dial-up phone bills higher) - and all that white-space and comments are for the designer's benefit. The user doesn't care about the human legibility of the HTML or your comments. The user wants speed. You're making the poor user pay, in terms of time and phone bills, for your urge for comments and readable code.

King even suggests, if you don't care about future browsers or validators, to leave off closing tags, minimise attributes etc to make the numbers of bytes downloaded smaller.

4: Advanced HTML optimisation

5:  XHTML optimization

On the other hand, a great way to make a site *seem* faster is to code it so
that the browser can start displaying the page before all the information is
received - a sort of 'streaming HTML', as it were. Minimising stuff in the head of the document cause the page to render faster. Use CSS rather than JavaScript for rollovers - and a proper DOCTYPE can help the browser begin rendering the page before all the information has been received by the browser.

If you really must use complex nested tables (every time you do, a fairy dies somewhere, remember) some extra mark-up can help the browser start constructing the page before all the information for each row and column has been received - the <thead> <tfoot> and <tbody> tags - used in that order, as well as the <colgroup> tag are nifty tricks that King explains. These don't actually make the table show any faster (in fact, because of the extra tags, it slows them down a little) but because the browser has enough information to start rendering the tables before it has received all the cells, it stops the user staring at a blank screen.

So, to make it appear faster, you can sometimes require extra mark-up, apparently contradicting the first law from chapter 3, to squeeze the html as much as possible. As with all things in web design, its a trade-off that only you can make, through trial and error.

The same is true of XHTML; because you have to close every tag and can't minimise attributes, there's more bytes of mark-up to download, but because it's standard and the browser doesn't have make its own decisions, it should render faster. CSS and XHTML seem to be reducing the average page size by between 25 and 50% (see http://www.webmasterworld.com/forum83/2093-2-15.htm)