Does it strike you as a bit strange that in the days where 8mbps ADSL is nearly universally available (in the UK anyway), some web pages are still pretty slow to load? Its not uncommon for a page that is mostly text with a few small images on it to take several seconds to load. If you haven’t noticed it, I am sure your visitors have…
Fair enough the size of some pages is pretty big these days but even taking into account TCP negotiating and overheads on a lot of small files, a home broadband connection should be able to download even the most tardy of pages (I’m looking at you here cnet.com and your 390K index page) in a couple of seconds max.
A Web 2.0 fashion?
Since the fairly recent explosion of interest in Web 2.0 sites, and in particular AJAX techniques, it seems to have become rather fashionable to have a load of javascript includes at the top of each page, with scriptaculous and prototype being two common names. Things have calmed down a little of late, but it was not uncommon to see anything up to 15 to 20 <script> tags at the top of a page. Its great that people are writing their code in a modular way. But there is one major flaw in this technique: it causes long loading times.
Clearly developers are aware of the bandwidth price of javascript as most have gone to the trouble and spent the time to “compress” their javascript down by removing as much white space as possible, but crucially they have left them in separate files.
The problem with using separate files is that browsers will, unlike with images, load each javascript file sequentially - i.e. one after another - before carrying on with multi-threaded downloading of all of the images and so on. Just take a look at the way Firefox downloads digg.com (click for a full-sized view):
As you can see, we are left sitting there waiting for about 3.5 seconds while the browser (in this case Firefox) is loading in the javascript files, after which we actually get to see the page as it loads in the pictures. And its not just Digg that does this - slashdot, blogger, and script.aculo.us are just 3 other examples where you stare at a blank page whilst the status bar twitters along as you wait for the page to appear.
The beady-eyed amongst you will no doubt have noticed that CSS files are treated the same too. Fortunately most sites seem to make do with one or two CSS files, but I have seen a couple of sites that decided on a separate CSS file for headings, another for the layout, a third for links - you get the idea! Luckily it doesn’t seem like this CSS “modularisation” has caught on like it has with javascript!
Optimise Loading Times
Some may argue that once the javascript files have been loaded once, they will be cached and so the page load will be much quicker next time. A fair point, but the first few seconds are vital in making a good first impression - if you site feels slow and bloated the first time they try and visit it, the user might just give up and try the next site before yours has even loaded!
A simple solution to this problem is just to copy and paste all (or as much as possible) of your javascript into a single file for use on the live site, after all designers are already going to the effort of “compressing” the javascript before using it on the live site, so why not go further and try compiling (obviously not compiling like with a conventional programming language!) the javascript into a single file as much as possible first?
Here is a quick look at the benchmarks for a quick test I did - 5 fairly large javascript files loaded seprately, compared to the same javascript in a single file…its about 25% quicker loading a the javascript as a single file (click for a larger view):
Having placed all of the javascript into a single large file the average home broadband connection should be able to download it in one single operation, quickly allowing the browser to continue loading in the rest of the page, hopefully leaving your user with the impression of a fast, responsive site they’ll want to come back to!