Looking through the web for standards on how to make your web pages more performant (i.e. using tools like YSlow!), one of the things that is mentioned is to put your css at the top and your javascript at the bottom. The reason to do this is so that your content will render faster (and be styled) and not have to wait for the parsing of the javascript in order to display.

Recently I have been getting into using jQuery UI a lot more. I like the common look and feel, the ability to theme it easily, and am excited for all of the new enhancements and widgets that are coming. The issue that I have found is that when jQuery UI initializes your widgets it adds the theming classes from the javascript. This causes the page content to render (in a very ugly unstyled fashion) and then it “pops” into the nice styled page. As a user also, I tend to hate this effect and find it very annoying. So I set out to see what I could do to fix this and still keep the site performant.

First attempt – pure CSS

At first I thought, well what if I just put the jQuery UI classes on the elements that I know will already receive those classes when jQuery UI ran? This worked well for some of the page but there were still issues:

1. Some of the jQuery UI widgets add in extra DOM elements to accomplish the look they are going for, so this still had the jumping effect
2. I was now bound to a specific version of jQuery UI because if they ever changed or tweaked their class names I would have to update all of my elements with the changes
3. By adding the classes on the server I increased the page size and content that needed to be downloaded to the browser

Second attempt – rearrange the JS

Since the CSS way wasn’t ideal and would cause a lot of maintenance I decided to see what would happen if I rearranged where I loaded the JS. I put all of the JS back in the head tag, so it would load (and parse) the JS before any content would display to the user. This solution was better, however, there was still a little jumping of the page before it was fully styled.

Third attempt – tweaking the JS calls

Finally, I took a look at how I was calling the jQuery UI widget initializers. I found that I was calling them inside of jQuery(window).load call. I then did some research and realized that the difference between jQuery(window).load and jQuery(document).ready is actually pretty significant if you have a lot of images. This is due to the fact that window load waits for the images to finish before being called where as document ready is called when the DOM is finished loading. Changing those calls to be inside of a jQuery(document).ready block did the trick and the page loads without any jumping.

So from this exercise I found that as the web world moves towards more and more javascript based UI’s we will need to look more closely at these blanket performance statements and include usability in those measurements.

Extra nugget:

The pages in question above also load various content through ajax after the page loads. I found a small performance gain when I kept the jQuery UI initializers in the document ready block and moved the ajax calls into the window load block.