Heres another little peice of Javascript trickery that I had to dig around because the situation commaned it. In one of my web sites, I had this situation where I had to implement “windows.onload” twice. The first thing that would came to an inexperienced mind like mine ( I have to honestly say that, since I have been using javascript Frameworks and libraries, I have forgotton to do simple things on my own… sad but true), is the following method…

window.onload=onloadfn1;
window.onload=onloadfn2;
window.onload=onloadfn3;
etc...

Sorry to say but, this wont work… dont want to discuss the execution science of Javascript much … but according to my recent experience, only the last function (onloadfn3) will ill actually get executed.

In normal situations, unlike mine (which I’ll talk about a little later)… you could do one of the following to execute mutliple onload functions ….

OR something like this

function doOnLoad() {
        onloadfn1();
        onloadfn2();
        onloadfn3();
}
window.onload = doOnLoad;

For my current situation , I cannot use either of the above…
Why did I need to call windows.onload twice, rather that calling two functions within a single onload function? Here is quick look at my problem statement…

“My Site pages are structured like the WORDPRESS theme…. i.e. there is a common Header.php and Footer.php that gets included into all the site pages. There is an onload function implementaion in the Footer.php to do some common onload functions. AND there are few pages that need to something of their own ONLOAD , apart from those done by the common onload function. If I assign callback function directly to the window.onload handler, it will over-ride previously assigned callbacks in the Footer.php”

…. Is my problem understood ?

Well! there are few solutions that I did find. They all are very similar and mainly implementions of a solution given by Simon Willison (http://simonwillison.net/2004/May/26/addLoadEvent/)…

Solution :

Simply add this javascript code to site …

function addLoadEvent(func) {
    var oldonload = window.onload;
    if (typeof window.onload != 'function') {
       window.onload = func
    } else {
       window.onload = function() {
           if (oldonload) {
                  oldonload()
          }
          func()
       }
   }
}

And call it instead of the usual “windows.onload”

addLoadEvent(FunctionToRunOnPageLoad);
addLoadEvent(function() {
/* more code to run on page load *
}); 

Advantages of this code snippet …
1. Primarily, It lets you have multiple windows.onload events, called from seperate parts of your code, without overridding the previous definition
2. It is really unobtrusive. It can be placed in a file with your other scripts or in a separate file.
3. It works even if window.onload has already been set.

More the DOM elements on the page, slower it renders, slower is the DOM access in JavaScript’s. A high number of DOM elements can be due bad layout design. For instance, nested tables might have been used for layout purposes. Use any HTML Tag where is makes sense semantically. For E.g. DONOT use tables for layouts, but DONOT hesitate to use them where you have to display tabular data, and hence will use reduce DOM elements, in comparison, to a similar structure created using DIVs only..

To test the number of DOM elements in your HTML page, just type the following in the Firebug’s console:document.getElementsByTagName('*').length

There is no set standard as to how many DOM elements are too many. Check other similar pages that have good markup.Eg. Yahoo! Home Page is a pretty busy page and still under 700 elements (HTML tags).

Use GET for AJAX Requests

It has been found that when using XMLHttpRequest, POST is implemented in the browsers as a two-step process: sending the headers first, then sending data. So it’s best to use GET, which only takes one TCP packet to send (unless you have a lot of cookies). The maximum URL length in IE is 2K, so if you send more than 2K data you might not be able to use GET.
An interesting side affect is that POST without actually posting any data behaves like GET. GET is meant for retrieving information, so it makes sense (semantically) to use GET when you’re only requesting data, as opposed to sending data to be stored server-side.

Avoid Synchronous AJAX Calls

When making “Ajax” requests, you may choose either async or sync mode. Async mode runs the request in the background while other browser activities can continue to process. Sync mode will wait for the request to return before continuing.
Requests made with sync mode should be avoided. These requests will cause the browser to lock up for the user until the request returns. In cases where the server is busy and the response takes a while, the user’s browser (and maybe OS) will not allow anything else to be done. In cases where a response is never properly received, the browser may continue to block until the request is timed out.
If you think that your situation requires sync mode, it is most likely time to re-think your design. Very few (if any) situations actually require Ajax requests in sync mode.

Optimize Images

Optimization simply means keeping the size of the image small keeping the quality of image to the required level. There are loads of procedures that once can carry out to optimize images before they are loaded on to the server for delivery. The tools that we use for creation of these images (Photoshop, Fireworks etc) usually have tools that allow users to optimize the image for web use.
• Check the GIF’s to see if they are using a palette size corresponding to the number of colors in the image. When an image is using 4 colors and a 256 color palette, then the image could be further optimized

• Convert GIF’s to PNG’s where possible and see if there is a saving. More often than not, there is. Do not hesitate to use of PNG’s, as they are fully supported by most of the commonly used browsers. Expect of the animation capabilities a PNG can do what a GIF does, including transparency.

• For the images used in CSS sprites, arrange the images in the sprite horizontally as opposed to vertically usually results in a smaller file size. Also, combine images with similar colors in a sprite. This helps you keep the color count low, ideally under 256 colors so to fit in a PNG8.

• If you are using a favicon.ico, keep it small, preferably under 1K.

Use properly scaled/resized image.

Always try and use resized images, i.e. don’t use a bigger image than you need just because you can set the width and height in HTML. If you need to display a 100px X 100px image on the page, then do not use a scaled down 200×200px image.

Use Progressive Images

A web browser already renders Images progressively. To do even better, simply save your GIF or PNG images with the “interlaced” option, or your JPEG images with the “progressive” option.

There is ongoing debate among web users as to whether use of progressive image is a blessing or a hindrance. Also a progressive image weighs approximately 20% more than its non progressive counterpart. So , If you think you layout uses images that will not hamper the user –experience by it being progressive, feel free to do so.

Include JavaScript’s at the Bottom of the HTML Document

If you do not have document.write ( or any dynamic generation of page contents using javascripts) to insert part of the page’s content in your scripts, move the script include statement to the bottom of the page, before the end of the BODY tag.
The HTTP/1.1 specification suggests that browsers download no more than two components in parallel per hostname. If you serve your images from multiple hostnames, you can get more than two downloads to occur in parallel. While a script is downloading, however, the browser won’t start any other downloads, even on different hostnames.
There are also ways to dynamically create SCRIPT nodes and load remote scripts after the page is loaded using AJAX .

Externalise you JavaScript’s

Using external JavaScript files will result in faster loading of pages because the JavaScript files are cached by the browser. Inline JavaScript’s’ in HTML documents get downloaded every time the HTML document is requested. This might actually reduce the number of HTTP requests made but it subsequently increases the size of the HTML document. External JavaScript’s are cached by the browser; the size of the HTML document is reduced without increasing the number of HTTP requests.
Please note that, if users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets, there is a greater potential benefit from cached external files.

Pack Your Javascript Files

In case of JavaScripts , unlike CSS, the files could crunched using some standard algorithms that would give a reduced file size than simply removing spaces or tabs. An example of javascript packer can be found here http://dean.edwards.name/packer/

Get rid of any Duplicate Scripts

It is very unusual that entire scripts might be duplicated, but a review of the ten top U.S. web sites shows that two of them contain a duplicated script. Duplicate scripts but obviously reduces the performance by creating unnecessary HTTP requests and wasted JavaScript execution.
Also, in many instances, though the scripts names are different, there is a likelihood of duplicate scripts within the same page due to team size and number of scripts.

Minimize accessing DOM elements where possible

Accessing DOM elements with JavaScript is slow so in order to have a more responsive page, you should:
• Cache references to accessed elements
• Update nodes “offline” and then add them to the tree
• Avoid fixing layout with JavaScript

Separate Behavior from Content and Presentation

Just as we separate Presentation (CSS/XSLT) from Content (XHTML/XML), we should also separate Behavior (Javascript). This is called unobtrusive Javascript. Just as we link to external CSS files, we should link to external javascript files.

Instead of hard coding behavior into the content (e.g. onmouseover, onclick, etc.), behavior should be dynamically added to elements, classes, and unique elements (IDs) using the DOM. The foundational document, the content, should contain only valid XHTML/XML and no javascript.
Javascript should augment content by adding behavior. The content should remain useful and usable without javascript (or without full javascript support).

I have saved this article ages back, so Sorry! I dont remember the source … but it seemed useful , for us who have to be aware about the audience for whom we develop the site for … so here i is

Page weight can be used to determine the download time for a given page on a variety of Internet connection speeds. By way of example, the following table shows the download times for three different pages at a number of popular connection speeds.

Benefits of reducing page weight?

The positive impact of reducing page weight benefits both website owners and consumers. Potential benefits include:

1. Pages load faster. The most obvious impact of reducing page weight is that your website’s pages will load faster for visitors, regardless of their connection speed.
2. Lower page load times create more comfortable visitors. Visitors are less likely to become frustrated and go elsewhere if your pages load quickly. On the other hand, slow-loading pages are one of the surest ways to lose visitors and potential customers.
3. Faster load-times will contribute to increased conversion. More visitors will stay on your site longer. More of them will end up making purchases, signing up for your newsletter, or book-marking your site.
4. Your brand perception will be enhanced. Returning customers and first-time visitors alike will be more inclined to describe your site (and business) as “professional” if your pages load quickly.
5. Pages with clean, solid code will often be indexed more effectively by natural search engines.
6. Pages optimized for weight can actually save bandwidth charges on high-traffic sites. 100,000 pages each weighing 150 Kb will require twice as much bandwidth from your ISP than 100,000 pages each weight 75 Kb. For ISPs that charge for bandwidth used or for overages, this reduction can create significant savings on bandwidth charges.

Consider the following data, published in a report

Put Stylesheets at the Top

If you want a page to load progressively; that is, we want the browser to display whatever content it has as soon as possible, put the CSS at the top of the page inside the document HEAD. This makes pages appear to be loading faster, as this facilitates progressive rendering of the page. This is especially important for pages with a lot of content and for users on slower Internet connections.

It is a documented fact that to enhance overall user experience, it is important to provide progress indicators and visual feedbacks. To avoid having to redraw elements of the page, in case if their styles change, some browsers, including IE, blocks rendering of the page until the CSS is fully loaded. Because of this, the user is gets to see a blank white page.

The W3 HTML Specifications’ also states that the CSS must me include in the HEAD section of the HTML page. Also note that, In IE @import behaves the same as using <link> at the bottom of the page, so it’s best not to use it.

Avoid Using Browser Specific features

Filters : Use of filter increases memory consumption and is applied per element, not per image, so the problem is multiplied. Also, Filters are IE Proprietary, hence will not work as intended in other browsers. If you want transparent or gradient backgrounds, use 1Pixel with images.
Expressions : CSS expressions are a nice feature to have in CSS, but still is IE specific feature. Also, it is important to note that, these expressions are evaluated when the page is rendered and resized, scrolled and even when the user moves the mouse over the page. Needless to say this could affect the performance of your page. Hence in simple words ,Avoid using CSS expressions, unless you feel its pros’ weighs more than its cons’

Externalise you CSS

Using external CSS will result in faster loading of pages because the JavaScript and CSS files are cached by the browser. Inline CSS in HTML documents get downloaded every time the HTML document is requested. This might actually reduce the number of HTTP requests made but it subsequently increases the size of the HTML document. External CSS are cached by the browser; the size of the HTML document is reduced without increasing the number of HTTP requests.

Please note that, if users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets, there is a greater potential benefit from cached external files.

Pack Your CSS File

Packing or crunching your CSS is the practice of removing unnecessary characters from code to reduce its size thereby improving load times.

The CSS can me crunched by removing all the comments and any unwanted characters like white spaces, newlines etc.

For ages, I have thinking to consolidate all the BEST Practices , I have been reading every now and then. Finally! I did get down to put it to pen. I realized that It is going to be mammoth task creating this mammoth document , so I decided to dedicate an entire category to it, so I could keep adding stuff about best practices as and when i encounter them…

Well! the content here will be a amalgamation of my personal UI development Best Practices with those written by the standard developers like Yahoo , Google etc.

Watch this space and keep browing the Best Practices Category