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:
- 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
- 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
- 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.
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.