ArtzStudio » engineering http://www.artzstudio.com Dave Artz and his discoveries in web design and development. Fri, 03 Jun 2011 04:57:37 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Beating Blocking JavaScript: Asynchronous JS http://www.artzstudio.com/2008/07/beating-blocking-javascript-asynchronous-js/ http://www.artzstudio.com/2008/07/beating-blocking-javascript-asynchronous-js/#comments Wed, 23 Jul 2008 19:03:51 +0000 ArtzStudio http://www.artzstudio.com/?p=10

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!

]]> http://www.artzstudio.com/2008/07/beating-blocking-javascript-asynchronous-js/feed/ 7 Optimizing Web Performance with AOL Pagetest http://www.artzstudio.com/2008/07/optimizing-web-performance-with-aol-pagetest/ http://www.artzstudio.com/2008/07/optimizing-web-performance-with-aol-pagetest/#comments Fri, 11 Jul 2008 03:26:34 +0000 ArtzStudio http://www.artzstudio.com/?p=6 In this screencast, I walk through how to analyze your site using the reports generated by AOL Pagetest, and explain why and how to go about addressing your pressing performance issues. Come for the tool demo, and stay to learn about the anatomy of an HTTP request, the importance of CDN’s and keep-alives, and a handy Apache module to concatenate CSS and JavaScript. Leave me feedback so I can improve it, and enjoy!

]]> http://www.artzstudio.com/2008/07/optimizing-web-performance-with-aol-pagetest/feed/ 17