Eric DeLabarWeb 2.0 from a Web Purist and J2EE Developer

As I’ve covered before, ill-used JavaScript can lead to some serious performance problems, most of which are caused by simply not thinking about what the code is really doing. Recently I came across a site that provided digital photo printing, This site had a nice interface that allowed my to upload close to three hundred photos. On the resulting page, each photo was displayed with all of the available sizes as input boxes, which looked something like this. I liked the interface, but came across a very serious problem. The event handlers that updated the totals box ran on the keyup event and recalculated the total of the entire form! This worked fine with ten or twenty photos, but the 300 that I provided brought my browser to a screeching halt.

I’ve taken the liberty of creating a very simplistic mock-up of the form and a simplified version of the JavaScript, which is available in my examples section. The demo uses Firebug and Firebug Lite for logging just like I did in my dollar function article, and the benchmark class from that article as well. The site’s JavaScript was a bit more complex and actually did an AJAX lookup of the price on each keyup, but I’m more concerned with the JavaScript performance here, so I simplified the code to something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

var PhotoSelector = Class.create();
PhotoSelector.prototype = {
	initialize: function( name ) {
		var init = new Benchmark();
		init.start();
		console.debug( "Beginning Initialization!" );
 
		$A(document.getElementsByTagName("input")).each( 
			function( inp ) {
				inp.value = 0;
				if( Element.hasClassName(inp,"qtyInput") ) {
					inp.onkeyup = this.recalculate.bindAsEventListener( this );
				}
			}, this
		);
 
		init.end();
		console.debug( "Initialization Complete in " + init.inMillis() + " milli(s)." );
	},
 
	recalculate: function(e) {
		var calc = new Benchmark();
		calc.start();
 
		$("fourby").value = 0;
		$("fiveby").value = 0;
		$("eightby").value = 0;
		$("wallet").value = 0;
 
		var inputs = $("pictures").getElementsByTagName("input");
		for( var i = 0; i < inputs.length; i++ ) {
			var totalId = inputs[i].id.match(/([a-z]+)[0-9]+/)[1];
			var total = $(totalId);
			total.value = parseInt(total.value) + parseInt($(inputs[i]).value);
		}
 
		calc.end();
		console.debug( "Recalculation Complete in " + calc.inMillis() + " milli(s)." );
	}
}
var ps;
Event.observe(window,"load",function(e){ps = new PhotoSelector()});

Basically, on window load, this code grabs every input element, sets its value to zero, and binds an event handler to it. The event handler runs on key up and loops through every input box in the “pictures” list, and updates the totals inputs at the top of the page. As I said above, this code works fine with 20 pictures, but it starts getting slow around 300, and becomes almost unusable at 1000. Care to try 10,000? (Be careful, it crashes my browser!) To test it, simply enter values in the photo inputs and watch the totals boxes increment.

The main problem with this code comes from the recalculate function. Problem number one is my personal pet peeve, the dollar sign function is called at least six times! Well, I guess six times wouldn’t be terrible for the entire page, but it’s called at least six times on every key up event! Problem number two, the biggest problem, is the fact that this code re-crawls what amounts to the entire DOM every time the event fires. Obviously the larger the DOM, the more time this is going to take.

So, how do we fix it? Well, here’s how I fixed it, I’ll explain the details below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

var PhotoSelector = Class.create();
PhotoSelector.prototype = {
	initialize: function( name ) {
		var init = new Benchmark();
		init.start();
		console.debug( "Beginning Initialization!" );
 
		this.old = 0;
		var totals = {
			fourby: $("fourby"),
			fiveby: $("fiveby"),
			eightby: $("eightby"),
			wallet: $("wallet")
		};
		totals.fourby.value = 0;
		totals.fiveby.value = 0;
		totals.eightby.value = 0;
		totals.wallet.value = 0;
 
		$$(".qtyInput").each( 
			function( inp, index ) {
				inp.onfocus = this.enter( inp, this ).bindAsEventListener( this );
				inp.onblur = this.recalculate( inp, totals, this ).bindAsEventListener( this );
			}, this
		);
 
		init.end();
		console.debug( "Initialization Complete in " + init.inMillis() + " milli(s)." );
	},
 
	enter: function( inp, me ) {
		return function(e) {
			me.old = parseInt(inp.value);
		}
	},
 
	recalculate: function( inp, totals, me ) {
		var type = inp.id.match(/([a-z]+)[0-9]+/)[1];
		var total = totals[type];
		inp.value = 0;
		return function(e) {
			var calc = new Benchmark();
			calc.start();
 
			var newVal = parseInt(inp.value);
			if( me.old > newVal ) {
				newVal = ( me.old - newVal ) * -1;
			}
			total.value = parseInt(total.value) + newVal;
 
			calc.end();
			console.debug( "Recalculation Complete in " + calc.inMillis() + " milli(s)." );
		}
	}
}
var ps;
Event.observe(window,"load",function(e){ps = new PhotoSelector()});

To solve problem number one from above I created a simple object for storing references to all of the total input boxes (lines 9-14), now we have a simple associative array lookup whenever we need to update a total. Problem number two is mainly solved by recording the original value of the input on focus (line 22, 31-35), and then comparing them on blur (line 23, 37-54). Because we’re doing this on blur, we can update only the necessary total input (lines 45-49) instead of recalculating the entire form. I made one final tweak, mainly to make solving problem number one easier, and that is the recalculate function now returns a specific event handler for the given input so that the event handler itself does not need to call the dollar function.

So, comparing these in my regular, not-very-scientific fashion, I came up with the following results. I chose to measure the startup time, which will increase with the size of the page, as well as the event handler time. I also measured these times across a pretty decent amount of pictures, and across a few browsers.

Safari (OS X)

Internet Explorer 7 (Windows Vista)

28 seconds!? Why!?

Firefox 2 (Windows Vista)

The results pretty obviously speak for themselves, but there is one caveat, be sure to notice the initial load time. Since the event handlers still need to be assigned to each input on the page the more inputs there are the longer the page load takes, and the load time is even slightly slower on the optimized page. Be sure to consider this time, possibly by capping the number of inputs displayed, since the code itself is very processor intensive and appears to actually hang the entire computer while processing. Obviously, these fixes become more important as the number of inputs grows, but any speed increase when the user is directly interacting with the page is a good one!

Let’s face it, cross-browser JavaScript and AJAX without a helper library or framework is pretty difficult. However, these libraries can be pretty hefty when it comes to page download size, especially if sent uncompressed and un-optimized. Most of the libraries have a statement in their docs that says something along the lines of “grow up and compress your JavaScript” but not all of us have sufficient access to their web host to actually be able to do that. Enter Google. Google’s AJAX Libraries API serves as a content distribution network for providing pre-compressed versions of the web’s favorite Web 2.0 JavaScript libraries:

• jQuery
• prototype
• script.aculo.us
• MooTools
• dojo

Access to these libraries is quite simple, in fact loading prototype can be accomplished with the following four lines of code:

<script src="http://www.google.com/jsapi"></script>
<script>
	google.load("prototype", "1.6.0.2");
</script>

Pretty simple, but let’s look at some metrics.

As you can see, the Google version is significantly faster and smaller on the initial load, subsequent loads a little less obvious, but still slightly faster. However, this test was not all that scientific, since I really only have the ability to do this with Firefox and Firebug, I only did it once, and my network speed can vary significantly from request to request. Despite all of that, testing this across a few other browser/OS combinations does reveal a pattern where the Google AJAX Library API pages do feel faster, even if only by a fraction of a second. I’ve provided my test pages, with Google and without-Google, for you to perform your own tests, and I’d love to hear what other people think and see their results.

The verdict, I like it, but I have a few caveats. First, as pointed out to me by the Unscrutable Designer, you’re relying on a third party site to host your scripts, in this case it means you need to trust Google to not be evil. Personally, I do, but that is a decision to be made on a case-by-case basis. Secondly, you have to trust the reliability of your content distribution network, can you risk your JavaScript functionality if Google’s server goes down? Thanks to progressive enhancement, having no library should be basically the same as no JavaScript, so my properly implemented site should still function, so this is personally not a show-stopper for me.

Now, one last thought. Keep in mind that this is not the most optimal solution since it still makes a request for each library you load and the libraries themselves are not optimized, but it does bring along with it an interesting benefit. The more sites that use this service the higher the chance of getting a local cache hit on one of these files, which of course means one less download.

From what I’ve seen, most of the popular JavaScript frameworks out there provide some form of the $ method. This method is usually a cross-browser translation of document.getElementById with a few extras. What this means is instead of always having to type document.getElementById("myId") you can now type $("myId"). All-in-all it’s a very nice shortcut and will probably cut quite a bit of typing out of your JavaScript projects. My problem is with the number of times I’ve come across inefficient uses of this helper function because it’s easier to type. This usually manifests itself as something along these lines (this example written using prototype.js):

1
2
3
4
5
6

if( $("myId").style.display.toLowerCase() == 'none' ) {
	$("myId").style.color = 'red';
	$("myId").style.height = '10px';
	$("myId").style.width = '100px';
	$("myId").style.display = 'block';
}

This code looks pretty concise, if you know what the $ function does it’s also pretty simple, but take a second to think about performance. In this code it’s possible that you’re calling document.getElementById five times! Ignoring whatever else the $ function does, the document.getElementById function could traverse the entire DOM on each call. (I’m not saying it does, but you really don’t know what the browser is doing under the covers and since you’re designing for all JavaScript enabled browsers, it’s better safe than sorry!) If you actually had to type out the document.getElementById you would probably consider something like this:

1
2
3
4
5
6
7

var myId = document.getElementById("myId");
if( myId.style.display.toLowerCase() == 'none' ) {
	myId.style.color = 'red';
	myId.style.height = '10px';
	myId.style.width = '100px';
	myId.style.display = 'block';
}

With this code, you’re only calling document.getElementById once, and therefore only traversing the DOM once. Makes a little more sense right? Let’s look at some metrics.

For this experiment, let’s make the assumption that the larger your document is the longer it will take to perform a DOM traversal, so in order to see some results we’ll need a decent sized document. For that we’ll go to wikipedia and grab something off the front page, in this case it’ll be Harry Potter. To get my test document I viewed the source, grabbed the main body content, and pasted it into a new HTML document. I also removed all of the images since I didn’t want broken images or to be hitting wikipedia’s servers for my experiment. I wrote a quick JavaScript class that will do my benchmarking, and a quick test case that calls my two methods above as well as two other methods and single calls to both the $ function and the document.getElementById function. To perform the benchmark, I run each method 1000 times. I initially tried smaller numbers but there was not enough visual difference to prove my theory since JavaScript is only accurate to the millisecond. You can find the test code here, the benchmark class here, and you can run the test here. I’m using Firebug Lite for the console logging, but if you have Firebug installed it will use the Firebug console. As I said before I just wrote the benchmarking class, but look for a future post and improved version now that the seed has been planted.

I have successfully run the test on Safari 3.1 on OSX 10.5, Firefox 2.0.0.13 and IE 7.0.6000.16643 on Windows Vista Business 64-bit, and IE 6.0.2900… and Safari 3.0.4 on Windows XP Pro. My results were as follows:

Across the board the optimized functions performed better, and in most cases the $ function was slightly slower than the document.getElementById function. The most surprising result is Safari on Windows because it’s actually the slowest machine that these tests were run on. The only problem that I can think of with this test is that it does quite a bit of looking up by id, and that’s probably not an accurate test case, but even if you’re cutting out only a few milliseconds on an event, somebody will notice the improvement. I’m welcome to any suggestions or comments on my testing methodology.