I have blogged about this before, but right now I’m happy to repeat myself: The Yahoo Developer Network has excellent advice on how to optimize load time for your web pages, and the best thing is that so much of it can be easily implemented.

Yahoos Rules for High Performance Web Sites start from the somewhat amazing observation that it’s not so much the response time of the server the time it takes the server to generate the page that slows down a web site but the things that happen after the HTML has been sent to the client.

Most relevant for my case was that a) the browser makes a new http request for each ressource (style sheet, script, image etc) in the page (and the more request the slower the page) and that with external javascript files progressive rendering is blocked for all content below the script, meaning the rest of the page will not render before the script files are downloaded. An easy workaround is to call the scripts near the page bottom (though there might be scripts where this is not possible).

I’m working on a site that uses prototype and various parts of the scriptaculous effects library, and I ended with six external javascript files. When I moved the script tags from the head section to the bottom of the page the load improved from about six seconds to two seconds (how do I know? I used Yahoos yslow to measure site performance).

Now you might say that two seconds over a DSL connection is still pretty slow. But so far I have tripled load speed and it didn’t cost me more effort than a single cut and paste action – I call that amazing.

I think most of Yahoos rules make sense only if you work on large sites with tens of thousands millions of visitors – I certainly will not set up a Content Delivery Network for a site with a few hundred visitors per day. Even so I think this proves that looking at the big boys can be a valuable excercise for us one man shops.

I any case I’ve ordered Steve Souder’s (Yahoo! performance chief) book High Performance Web Sites – I don’t know if there’s anything in it that I couldn’t find as well on the YUI-Blog, but to buy the book seems a nice way to appreciate his work.

A couple of days ago thelist – the mailing list of the evolt web developer community – had a short discussion about javascript libs (like e.g. jquery). Do they help with coding or not – i.e. do they help you to become an actual programmer or are they a simple way to do nifty stuff that you don’t actually understand?

I couldn’t contribute to the discussion, but still I’d like to mention here one of my problems with libraries. I often take over maintenance for sites that have been deserted by their original programmers, and usually when one of these web geniuses spontaneously combusts he burns with him all documentation. One of the sure signs of a web prodigy is that comments in the frontend code usually fail to tell anything useful. Instead I find little essays on why “Javascript sucks”, which is why they have used this amazing library (usually nebulous 0.1 or the promiscuous 0.0.5 pre-alpha) that allows for otherwise unsurmountable tasks like adding a rollover to an image or toggle display of a named element (and even if they used one of the better known scripting frameworks there are still at least a ten or twelve to choose from). So instead of programming in the one language javascript, which I by and by get the hang of (mostly due to Christian Heilmanns excellent book and web site) I suddenly have to look up documentation for a dozen or so libraries. And sometimes I wonder why my predecessors bothered at all to include a couple of hundred kb worth of Javascript when they then decided to rather use some method they’d concocted themself.

This is of course not an argument against libraries – I think by now it would be somewhat insane to built a Rich Interface Application without a javascript framework – but I still have to say that the purpose of libraries is often defeated at my end, when simple Javascript would be much easier to understand and maintain.

My suggestion would be not to use libs for the more mundane tasks but rather small, well documented scripts, never to include a library (or worse, multiple libraries) just because it has one effect that you particularly like and, if you can’t help to use a library then to actually use it and not replace parts of it with your own functions.

And if you are interested in Javascript your really should visit Chris Heilmanns web page wait-till-i.com (it feels a bit strange to advertise for him, since he’s some kind of web guru and I’m a goofball from Berlin, but still). While many people still look at JS as something that is slapped on top of a web page he sees it as a regular programming task, which means that the task at hand gets analyzed step by step before he starts writing code. I tried it and was amazed how much time you can save by taking the long way round.