Beating Blocking JavaScript: Asynchronous JS

Bookmark and Share

Jul ‘08 23

MSN is now implementing a technique for loading JavaScript in a way that doesn’t stall the rendering of the document. They use Dynodes, a technique I also recommend for loading functionality on demand so it only consumes bandwidth when it is needed.

JavaScript Blocks Everything

To see the problem, view a Pagetest waterfall report of pretty much any website today, or see this recent run of AOL.com. Notice that 1 second is spent downloading and executing JavaScript, one at a time.

waterfall graphic of aol javascript blocking rendering

One by one, folks! This is how all browsers load JavaScript (unless the defer attribute is used in IE) when called from your standard HTML <script> element.

However, viewing a waterfall report of MSN, we can see that they call 3 JavaScript files (dap.js, hptr.js, and hp.js) asynchronously, and allow the subsequent CSS files to load right away.

waterfall graphic of msn javascript not blocking

Had their scripts loaded in the standard way, dap.js, hptr.js, and hp.js would delay the page for 1.4 seconds!

Loading JavaScript Asynchronously

MSN is using standard DOM functions to create and append a script element to the HTML document’s <head> element. This technique, originally coined as Dynodes, is encapsulated in a JavaScript loader, much like the one used by JS frameworks such as Dojo.

We downloaded and formatted the MSN.com HTML source code so you can have a closer look at it. Start on line 297 which kicks off a process to a function aptly named JS:

(function(){}).JS(Msn.Page.Track).JS(Msn.Page.Js)

Note that it is passed in two URLs defined back on Lines 13-19:

Msn={
	Page:{
		SignedIn:'False',
		Js:'http://stj.msn.com/br/hp/en-us/js/46/hp.js',
		Track:'http://stj.msn.com/br/hp/en-us/js/46/hptr.js',

The JS function kicks off a method that pulls down these two scripts. Take a look at line 130 to get to the heart of this technique:

var c=g.createElement("script");
c.type="text/javascript";
c.onreadystatechange=n;
c.onerror=c.onload=k;
c.src=e;
p.appendChild(c)

The <script> element (c) is appended to the <head> element (p), as defined back on line 113.

MSN also appears to be closely monitoring the load of all the scripts called by JS, in case something happens during the process. Event handlers are set on readystatechange, error, and load to stop the polling process (fired every 100ms) once the script is finished.

Their code is quite obfuscated and difficult to follow, but you can look for the timeout function on line 125. There also appears to be an optional parameter to kill the process after a specified period of time.

JS Loader Prototype

We designed a JS Loader Prototype (not nearly as fancy as MSN’s) that illustrates the benefits of this technique, and tested behaviors in IE and Firefox.

In our prototype (we strongly suggest you view the source now), the code is organized into 4 sections:

  • JavaScript #1 and #2 are called from a <script> block in the <head> using our JS Loader function.
  • JavaScript #3 and #4 follow next, called by the JS Loader in a <script> block in the <body>.
  • JavaScript #5 and #6 are called after some text again by the JS Loader, from a second <script> block in the <body>.
  • Finally, #7 and #8 are loaded in the traditional, HTML <script> element fashion.

In Internet Explorer, the script files queued up normally and the screen was not blocked for any period of time (until #7 and #8). Notice a very short Start Render time in our test run at Pagetest, and JS loading as fast as HTTP1.1′s 2 connection per domain limit will allow it:

waterfall chart of js loader prototype in ie showing full asynchronous load

In Firefox, however, any content below the next inline HTML <script> section is blocked until the scripts from the previous inline HTML <script> section called by the loader are complete. You have to see it to believe it!

waterfall chart of firefox blocking until all js has download in each script block

Notice in the above chart, within each script block both JavaScript must fully load before the next script block is allowed to start processing. The takeaway here is to include as many JS Loader calls as possible in one script block.

We developed a workaround for this issue by including a timeout delay before calling the script. This allows Firefox to continue rendering like IE and Safari, and affords the fastest possible download. See the updated JS Loader Prototype for Firefox here.

waterfall of updated prototype showing that firefox no longer blocks other scripts

We put a longer delay on the first script (10 seconds) so you can see that Firefox no longer waits until the script block has completed before loading others. The important bit of code looks like this:

js:function(url)
{
	// If you want to call IE and Safari straight up without the delay, uncomment this.
	// (navigator.userAgent.search('Firefox')) ? js = setTimeout("artz.create('"+url+"')", 0) : artz.create(url);
	js = setTimeout("artz.create('"+url+"')", 0);
},
create:function(url)
{
	s = artz.ce('script');
	s.type = 'text/javascript';
	s.src = url;
	artz.tag('head')[0].appendChild(s);
},

You will be pleased to know that Safari renders much like IE, with the added benefits of 4 open socket connections!

waterfall shot of safari with 4 open socket connections

Hopefully the benefits to this approach are clear. With a large site like MSN faithfully using Dynodes for their scripts, it might just be the time to standardize on this approach.

Race Condition Challenges

Not so fast! (pardon the pun) There are some additional considerations we will need to think through when moving in this direction.

  • JavaScript functions in the external scripts may not be available when inline HTML JavaScript functions call for them.
  • Along the same lines, even if Script A is called before Script B, Script B may finish and execute before Script A.
  • DOM elements may not yet be available in the HTML should an external script need them to hook events, access data from, etc.

In tackling the above, we would first recommend following the Progressive Enhancement approach, and work to completely eliminate inline HTML JavaScript function calls. The external scripts can latch any events needed on to links, buttons, etc., once they are ready.

While race conditions may still exist, a way to solve this is using the setInterval function to initialize your functions where you know a race condition may exist.

function id(id){return document.getElementById(id)}

var oranges =
{
	init: function()
	{
		if(id('oranges'))
		{
			clearInterval(oranges_init);
			alert('We have oranges!');
			// We may proceed with orange code!
		}
	}
}

oranges_init = setInterval("oranges.init()", 100);

We recommend using a period of 100ms to go easy on the CPU, and still feel instantaneous to users. To see this code in action, have a look at our ID Polling Prototype.

Document.Wrong

External scripts loaded that include the infamous document.write method executed by the script will cause problems with this technique. Be sure to wrap it in a function and call it from the HTML if you decide to head down this path. We hope that by now, you have thrown this ancient tool away.

Advertising vendors…this means you!

Final Thoughts

This technique has been on the back shelf for some time due to the tricky Firefox and race condition issues.

That said, if we are careful, and with MSN proving its value, now just may be the time to adopt Dynodes as a standard JavaScript loading practice.

Leave us a comment with your thoughts, questions, and concerns, and post links to implementations that leverage this!

Tags: , , , , , ,

Bookmark and Share

7 Responses to “Beating Blocking JavaScript: Asynchronous JS”

  1. Stoyan barked... July 26th, 2008 at 2:43 pm

    Heh, I wrote about this pretty much at the same time :)
    http://yuiblog.com/blog/2008/07/22/non-blocking-scripts/

  2. ArtzStudio quacked... July 26th, 2008 at 4:16 pm

    A day before me, doh! I see you didn’t notice the Firefox snag that I ran into, what are your thoughts on that? It seems like Firefox lacks the ability to do two things at once, execution-wise (like me).

  3. Dan proclaimed... August 8th, 2008 at 12:38 am

    One common recommendation I’ve seen to avoid the JS blocking issue is to move the JS script tags to the bottom of the HTML file. How do you think this technique compares to the one you’ve outlined here? Is it better for the JS to be in the header and start the download sooner than it would’ve been when located at the bottom of the HTML file?

  4. ArtzStudio notified... August 8th, 2008 at 7:15 am

    If the functions contained in the JavaScript are more important than other assets (like template images, content images) on the page in terms of perception that the page is loaded and ready, then you should use the Asynchronous JS method.

    JavaScript can be engineered so that you would never know it was there until you did something (usually after the page has loaded), a technique called Progressive Enhancement, but the user gets to that Photo Gallery Next Button and clicks Next before your JavaScript has downloaded, it may be an undesirable experience.

    If your web page is JavaScript rich and has many interactive widgets that get a lot of usage, I would recommend going for the asynchronous method to ensure they are initialized as soon as possible. If your page is mainly content and JavaScript is used to spruce up the place, I would recommend loading them at the end of the page. You could even still use the Asynchronous method and set them to load on the window.load event, effectively after everything else has loaded.

    Incidentally, this is why it is not a rule in AOL Pagetest to load JS at the bottom. It will make your content appear faster, but at the expense of an unenhanced or broken UI. I will blog about my Progressive Enhancement solutions here in a future post.

  5. Vladimir Dzhuvinov notified... September 15th, 2008 at 1:07 am

    Hi,

    I don’t know how versed your readership is, but in case there are any casual readers, it would be good first to explain to them that browser interpreters “block” script execution for a good reason:

    http://www.mozilla.org/js/language/js20-1999-03-25/execution-model.html

  6. Arup squawked... October 7th, 2008 at 4:06 am

    This implementation has several disavantages also . Like page timeout functionality . Sometimes the ojects are set to null and js not works on the page .

  7. Arup touted... October 7th, 2008 at 4:08 am

    I have worked in this async loading js and it is live on uk.msn.com . I will coming up with few features of this later.

Leave a Reply

Please index me, experiment!

“Don’t you want a little taste of the glory! See what it tastes like!” — Nacho