Click here to print.
Click here to print.
Posted By Christian Heilmann On 30th January 2007 @ 08:40 | 40 Comments
One of the biggest obstacles to tackle in web site and web application design is the initial response time of the product. There is a common feeling among web users that things just don’t happen fast enough.
Why is this such an issue? Perhaps people who’ve been using the web for years remember the times when we had to pay by the minute (in the way that hotel or airport users do even now), or there could be just a general feeling of being let down by the promised information superhighway. I think in part it’s Hollywood’s fault: in every action flick there are high-resolution, data dense animated web interfaces that show up at the touch of a button, and encyclopaedic data gets loaded and displayed in a matter of milliseconds.
In real life it is simply not the case, because no matter how much you try to streamline your pages, there are always delays. In the case of a web site, apart from the general lag, it is often a cosmetic issue - especially when there are flashes of unwanted content. With web applications it can be more problematic as you have to make sure that visitors cannot activate interaction elements prematurely and break the app.
Whenever talk comes to the speed of web sites the biggest trick usually advertised is to cut down on the file size of everything (this also leads to endless - and fruitless - discussions about the size of JavaScript libraries [*edit]1). In reality, there are many more factors that play a part in the initial response time of a web page:
These are the technical parts of the equation. Then there is also the human factor. Web pages are considered to be not fully loaded until they show up and don’t “jump around” or “have no loading images”.
There are some well-known general best practices you can follow to overcome some of these technical and human factors and ensure a quick response web site:
Unfortunately some of these tricks clash with what we consider best practices in web development. Cutting down on the number of included files for example impedes maintainability of the product. In order to make it as easy as possible to maintain the look and feel of a site with different pages (home, articles, archive…) it does make sense to keep the different styles in own includes and only add them to the pages that really use them. You could have one base CSS include and then one for the homepage, one for articles and so on.
The same applies to scripting - keeping methods that do the same job in their own JavaScript includes makes maintenance a lot easier, as you know immediately where to find a certain method without having to scan the whole script. Furthermore, adding scripts inside the body of the document is dirty as it mixes the web development layers structure and behaviour.
Luckily there are technical solutions for most of these problems.
One solution, written by Edward Eliot2, is a PHP script that does the job of collating several scripts or CSS style sheets into a single file3. In the case of JavaScript it even cuts down on the size of the script using Douglas Crockford’s JSmin4. The script is dead easy to use and will cache the collated file for you until you change one of the files included in it. This means that your files are automatically packed, cached and the include file updated when you change them. You get the best of both maintenance and speed without having to change anything by hand.
One other really big issue is that unless you embed your scripts in the body of a document you’ll have to start them when the document has finished loading. This results in a slight delay, and can cause problems.
The delay is caused by the way browsers load, parse and render documents. If you call your scripts with the onload event on the window, all of these following steps will have to be finished:
In a lot of cases, this takes far too long and needs to happen a lot earlier. Many5 clever6 web7 developers8 are9 tackling this issue and every so often a new answer to end the quest for a solution gets released. Most JavaScript libraries have an onAvailable10 or onDocumentReady11 event handler that starts the script as soon as parts of the document are loaded rather than the whole lot including images. In practical and admittedly hard-core testing with older browser and operating systems none of them really turn out to be bullet proof though. However, we are all on the case and with luck we’ll get there eventually.
For web applications where a premature activation of elements can result in a failure of the app this is absolutely vital. If your problem is of a cosmetic nature, there might be a workaround.
Most cosmetic on-load issues are caused by overloading the document with far too much content. This could be massive amounts of text displayed in a tabbed interface or a navigation that is four levels deep. With JavaScript enabled and executed without a glitch, this content can be navigated and displayed in a dynamic fashion and easily digestible chunks. When you turn off JavaScript and see the whole document unstyled it can become a real pain to find your way through it and that is never a good plan. This extra content also adds unnecessarily to the page weight of the initial load.
The solution is to use JavaScript to load the content only when the clever interface can be offered to the user. Users without JavaScript would get a plain vanilla version that only has the most necessary elements and content.
Which techniques you use to pull this extra content will depend on what you try to include. The easiest option is to use a dynamically generated script tag. This is an old trick that was used to pull in large JavaScript data sets or scripts on the fly when the page was loading:
function pull(){
var s = document.createElement('script');
s.type = 'text/javascript';
s.src = 'largeJavaScriptBlock.js';
document.getElementsByTagName('head')[0].appendChild(s);
}
window.onload = pull;
This trick can also be used to include output of APIs that support JSON, for example del.icio.us. As a JSON object is nothing but a chunk of JavaScript you can include this with a generated script tag when the document has already loaded and is displayed to replace an element with this content. The wrapper object Dishy12 allows you to do this easily. Another example is the unbobtrusive Flickr badge13 that uses the JSON output of Flickr to show your latest photo when JavaScript is available but only a link to them when it is turned off.
In order to include non-JavaScript content you can use Ajax or AHAH or Hijax or whatever you want to call Ajax without the XML part! An example for this would be the optional Ajax navigation14 which goes even further as it only loads the more complex interface when the visitor wants it.
The last idea stems from a time that may just have been before you even started developing for the web! Netscape, the ill-fated (but IMHO at that time better) competitor to Internet Explorer during the browser wars had a custom HTML attribute for images called ‘lowsrc’ which enabled you to define an image that was of much smaller file size than the real one and was loaded first and then covered by the real one while it was loading. This allowed you to give even users on ridiculously slow connections a preview of what there is to come.
You can re-use that idea and not embed large mood imagery in the page when it is loading initially but use more stylized, lighter images that get replaced with the others once the page has been loaded. Or you could go even further and only use background colours at first. You then use JavaScript and the DOM to load the real image when the document has finished loading and cover the preview with it.
This trick can also be immensely effective when you include lots and lots of smaller images from several servers (like gravatars for example) as these are not likely to be cached. Simply use a placeholder graphic initially and replace them with dynamically created images when the page has loaded.
This is of course only an overview of what is possible, but I hope some of the suggestions make sense and will help you change your site or app to make it more responsive. If you have more tricks, don’t be shy - comment about them.
Like this article? Digg it15!
Article printed from Vitamin Features: http://www.thinkvitamin.com/features
URL to article: http://www.thinkvitamin.com/features/dev/enhance-your-page-performance
Click here to print.