FF: Website optimization

29th August 2008

One of the things I’ve realized when I started working for Yahoo! is the importance and “interesting-ness” of website performance optimization. In an industry where things can get repetitive (how many <p> tags can you code in one day?), the challenges brought about by ensuring a website is properly optimized in terms of performance and page load is welcome and quite engrossing.

With high-speed Internet, a lot of times we tend to forget about the size of the files we put up on the Internet on our websites, much less worry about how long someone takes to load our website. It’s easy to forget, but when you’re on a crappy dialup or using your mobile phone as a model (er, like me while transitioning houses!), or you’re, say, a trouble-checker for one of the fanlisting networks out there, the wait for websites to load can take its toll, and feel painful on the pocket.

Two reasons why optimizing websites — even if you’re not Yahoo! — are:

You keep visitors longer, because the wait time is less, and people like things faster than you can chug them out. It’s all about instant gratification these days.
You save on bandwidth! Something smaller by even 10kb can mean megs or gigs of bandwidth savings in the long run. If you pay for hosting and you have a fairly popular website, this is a big deal.

A lot of this work is done on the frontend side of things. After all, once the server has cobbled together the page, the bulk of serving the page code and objects rely on the user’s connection. The HTML code is just one part of what’s served out to people, but images, stylesheets and other media are downloaded all after the source is available. And these are the things that users see and perceive. The image below shows around a third of Firebug’s Network tab on one of my websites:

$Seasonal Plume under Firebug\'s Network panel$

Building and serving out the page takes up only 715ms. But the rest of the objects on the page are then loaded, and I end up with a 4.08-second load time. That isn’t so bad, but all the rest of the objects on that page form the bulk of the load time that users have to endure. If we save a few milliseconds from each object, overall we can get a snappier load time for the whole page.

In The Psychology of Web Performance, Andrew King highlight a few interesting results of bloated load times, in case you’re still not convinced:

Google found that moving from a 10-result page loading in 0.4 seconds to a 30-result page loading in 0.9 seconds decreased traffic and ad revenues by 20% (Linden 2006).
Tests at Amazon revealed similar results: every 100 ms increase in load time of Amazon.com decreased sales by 1% (Kohavi and Longbotham 2007).

Over the next Frontend Fridays, I’ll talk a little more about some ways to optimize frontend performance. I’ll mostly be going through the rules Yahoo! has published, but I will probably cherry-pick and talk about the ones I like most, the ones I like doing. Stay tuned :)