Page style:

A Blue Perspective: JavaScript load placement

JavaScript load placement
29 September 2004

» Optimal place to load JavaScript that changes the web page «

Programming for the Internet is fraught with a whole host of things that you can't depend on, but for the moment I'll be satisfied with talking about one of them: timing.

Any JavaScript that affects the way a page displays – either its content or its styling – has to first make sure that everything it requires is there i.e. that the page it's working on is downloaded (and parsed). Traditionally (well, for the past couple of years) this requirement has been met in one of two ways: placing an onload function call on the body element, or placing an automatically executed script late in the content of the page. However, these two methods have their disadvantages. Namely, that they can take a while to execute and thereby account for a page flicker where the content is visible before it has been transformed.

To demonstrate this, I've created an example page where a set of tables is hidden using JavaScript and a select box is used to display a particular one. There are four different pages of differing size (content after the tables) and each page has three different methods of running the JavaScript which hides the tables.

The third method is one of my own devising: a scheduling script that runs as soon as the <head> scripts are executed, but which checks to see if the required elements (the tables) exist yet. If they exist they are transformed, if they do not exist the script is scheduled to run after a short wait (1 millisecond), whereby it checks again ... Here's the results:*

Time taken to load JavaScript that hides page elements (Firefox)

body.onload Content call JavaScript scheduler
Small page 1103ms 1081ms 1062ms
Medium page 1128ms 1150ms 1134ms
Large page 1531ms 2621ms 1534ms
Image 11331ms 1849ms 1015ms

Time taken to load JavaScript that hides page elements (IE 6)

body.onload Content call JavaScript scheduler
Small page 2250ms 1644ms 1437ms
Medium page 2199ms 1522ms 1475ms
Large page 2256ms 1566ms 1509ms
Image 12556ms 3050ms 1628ms

*Times were averaged out over 5 attempts for each combination over a 56kb connection. Cache was cleared for each attempt. Timing of execution was initialised by the first script in the <head> and terminated when the function that hides the tables was executed.

At first glance, large differences can be seen in body.onload initialisation between Firefox and Internet Explorer. IE seems to only regard <body> as loaded until after CSS background images have been downloaded, whereas Firefox appears to treat <body> as loaded once its code has been downloaded and parsed.

The filesize of the web pages doesn't appear to affect JavaScript load times too greatly, but it can clearly be seen that the introduction of an image file adversely affects body.onload initialisation. Content calling and scheduling were on a rough par, but improvements could be seen in the scheduler for larger files and images.

Given the poor performance of body.onload under varying circumstances, it would appear that this is not a good option for the initialisation of page transforming JavaScript. Content calls could be an alternative, but they do not guarantee that the required content will be loaded, and they also require alteration of the page content itself. Scheduling of transformation appears to be the safer and faster option, although it still does not prevent flickering of content.

And now, I'm off to Web Essentials ...


1/11. 29 September 2004 @ 03:58, Mark Wubben wrote:

Unfortunately things can get even more confusing. There's a good chance that Safari hasn't painted the page yet, even though the elements do exist.

The way I approached this in sIFR ( is as follows:
1) sIFR JavaScript is loaded
2) A window.onload event is set
3) The user can initialize sIFR from the body (just before it closes)
4) if sIFR is initialized and the browser is Safari or Mozilla in XML mode and sIFR isn't initialized through window.onload, wait. Otherwise proceed.
5) Initialize through window.onload, unless already initialized

This gives optimal results while not forcing the user to do anything themselves.

2/11. 29 September 2004 @ 06:29, Mike D. wrote:

Yep, what Mark said.

What we *really* need is some way to detect when CSS files have loaded and kicked in. onCSSLoad or something like that would be great. If anybody is aware of such a method, please let me know.

3/11. 29 September 2004 @ 14:06, The Man in Blue wrote:

If the object has loaded, but it hasn't been rendered yet (i.e. given height, width, etc.) I can see how that would be a problem for sIFR, given that you guys use the dimensions of the element itself to size the Flash (I think).

But it would be OK to otherwise interact with the object, no? e.g. change its content, class, etc. as this doesn't rely on existing appearance of an object to function.

4/11. 29 September 2004 @ 15:34, Mike D. wrote:

True dat... yes.

5/11. 29 September 2004 @ 20:55, Dale wrote:

Digressing a tad, I'd be interested in hearing what other people use to code their Javascript. Do you use a text editor/Dreamweaver like I do? Or are there nifty IDEs I'm missing out on?

Cheers... Dale.

6/11. 29 September 2004 @ 22:22, Unearthed Ruminator wrote:

For the most part, the content call method has worked out well for my needs, but I like the idea of the scheduler taking care of it (so I can avoid adding extra script elements on a page).

Dale, a quick Google scan for 'javascript editor' came back with over 2 million hits...I would be interested in hearing if anyone here uses a particular one or not (I'm still in text editor mode myself).

7/11. 30 September 2004 @ 19:37, Janne Kalliola wrote:

Mike, how about adding a redundant style definition at the end of the CSS file and checking in JS code whether it exists or not? If some browsers have long gaps between loading and executing CSS, the style could set a width, height or something and JS would check whether an element with that style would have the correct width, height or something.

8/11. 1 October 2004 @ 02:09, Kevin Cannon wrote:

Speaking of Javascript, what methods do you all use for multiple external Javascript files.

Is it possible to stack multiple scripts on to the onLoad command, or is there another way to go about that?

9/11. 2 October 2004 @ 14:29, Aaron Barker wrote:

I have often pondered doing some kind of checker/scheduler as you have described here, but was worried about the resource/process hit it would give a browser and/or system. Has anyone run a test to see what happens if for whatever reason the scheduler runs every millisecond for seconds on end, due to whatever reason. Would this adversely effect system stability and/or browser performance? What if you stacked multiple schedulers on top of one another and they ran for a while?

Will give it a go myself sometime this weekend if no one else has already done so. But thought I'd ask first.

Kevin - I ran into <a href="">addLoadEvent</a> from Simon Willison a while back that I have been using to do multiple onloads. Maybe that will do the job for you.

10/11. 2 October 2004 @ 14:31, Aaron Barker wrote:

doh... helps if you read the instructions to see what will happen to your HTML Apologies.

11/11. 20 October 2004 @ 05:02, Tanny O'Haley wrote:

In the past I have used the "content" call method but in the interests of separating content from presentation I have gone to the Simon Willison's Executing JavaScript on page load method. The only problem I have with this method is that if the page has graphics it can take a very long time before the JavaScript code executes. I like the idea of the scheduler because it is unobtrusive, but in almost every case on your sample page, the scheduler method actually took longer to execute than the onload method.

Usually I use javascript onload to allow drop downs (via suckerfish) or behavior like in a expanding collapsing tree. The only other time I use javascript is for form validation which usually does not need to be executed until the submit button is clicked.

Dale and Unearthed Ruminator, I use TextPad and load the javascript document class that gives syntax highlighting.

Post your own comments

Fields marked with an asterisk* are mandatory. All HTML tags will be escaped. http:// strings in comments will be auto-linked.