JavaScript load placement

29 September 2004

11 comments

A Blue Perspective: JavaScript load placement

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

Categories

,

Comments

  1. 1/11

    Mark Wubben commented on 29 September 2004 @ 03:58

    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 (http://www.mikeindustries.com/blog/archive/2004/09/sifr-2.0b2-mo-betta-beta) 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. 2/11

    Mike D. commented on 29 September 2004 @ 06:29

    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. 3/11

    The Man in Blue commented on 29 September 2004 @ 14:06

    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. 4/11

    Mike D. commented on 29 September 2004 @ 15:34

    True dat... yes.

  5. 5/11

    Dale commented on 29 September 2004 @ 20:55

    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. 6/11

    Unearthed Ruminator commented on 29 September 2004 @ 22:22

    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. 7/11

    Janne Kalliola commented on 30 September 2004 @ 19:37

    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. 8/11

    Kevin Cannon commented on 1 October 2004 @ 02:09

    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. 9/11

    Aaron Barker commented on 2 October 2004 @ 14:29

    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="http://simon.incutio.com/archive/2004/05/26/addLoadEvent">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. 10/11

    Aaron Barker commented on 2 October 2004 @ 14:31

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

  11. 11/11

    Tanny O'Haley commented on 20 October 2004 @ 05:02

    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 http://simon.incutio.com/archive/2004/05/26/addLoadEvent 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 http://www.textpad.com/ and load the javascript document class http://www.textpad.com/add-ons/files/syntax/javascript5.zip that gives syntax highlighting.

  12. Leave your own comment

    Comments have been turned off on this entry to foil the demons from the lower pits of Spamzalot.

    If you've got some vitriol that just has to be spat, then contact me.

Follow me on Twitter

To hear smaller but more regular stuff from me, follow @themaninblue.

Monthly Archives

Popular Entries

My Book: Simply JavaScript

Simply JavaScript

Simply JavaScript is an enjoyable and easy-to-follow guide for beginners as they begin their journey into JavaScript. Separated into 9 logical chapters, it will take you all the way from the basics of the JavaScript language through to DOM manipulation and Ajax.

Step-by-step examples, rich illustrations and humourous commentary will teach you the right way to code JavaScript in both an unobtrusive and an accessible manner.

RSS feed