Sunday 2 December 2007

Speeding up Dojo 0.9

Remember my previous article about Dojo ? What had to happen finally happened : one of our competitors released a website with a rich form powered by another Javascript framework. The catch ? Their form is faster than ours. Period. I've been told that investors are the first to complain about the loading time of our forms. The culprit was well-known : Dojo and its voracious parsing/initialization lag. My job was to speed up the beast.

Getting into the details

My first guess was that too much time was spent on two things :

  • loading the various files/packages needed to initialize all the Dojo widgets
Each class of Dojo widget requires its own package (e.g. putting a ValidationTextBox on a form requires the loading of TextBox.js and validate.js, each of them requiring a few more sripts to be loaded...)

  • parsing the DOM tree to "widgetify" the elements marked as such.
I assumed that too much CPU time was spent into the transforming of standard DOM input nodes into Dojo input nodes.

e.g.
<INPUT TYPE="text" dojoType="dijit.form.TextBox" id="firstname" />
is turned into :
<input id="firstname" class="dijitInputField dijitFormWidget" type="text" tabindex="0" maxlength="999999" size="20" name="" autocomplete="off" dojoattachevent="onfocus,onkeyup,onkeypress:_onKeyPress" dojoattachpoint="textbox,focusNode" style="" widgetid="nom" value="" valuenow="" disabled="false"/>
after parsing.

Getting asynchronous

As written in the YUI team's study, browsers can only download two elements simultaneously from the same domain. It implies that you can easily speed up downloads by creating alternate domains from where to download (hence the "transferring data from static.foobar.com" that appear sometimes in your toolbar while you're browsing foobar.com - they optimize the loading of their static content by serving it under a different domain).

Applying that rule to Dojo is a piece of cake since version 0.9, thanks to the AOL CDN. Instead of including your own, local version of Dojo, follow the guidelines and include the AOL-hosted version. Not only your scripts will benefit from the CDN and load with the same speed from any corner of the planet, but also -and more importantly-, they will be loaded from an AOL domain. As a consequence, your browser will be loading Dojo scripts at the same time as other resources from your page.

Disabling autoparsing

The thing to know is that parsing exists because Dojo doesn't know where to look for its widgets, and thus parses the whole document. In Dojo 0.9, autoparsing can be disabled by replacing djConfig="parseOnLoad:true" on the line which includes dojo.js to the document. Parsing can then be activated manually on all the children of a given DOM node :
dojo.addOnLoad(init);

function init(e)
{
   dojo.parser.parse(dojo.byId('myForm'));
}

As for the results...



Enabling parallel downloads from the CDN obviously speeds up the whole thing (6.38s to 2.57s to load the whole page).

However, as opposed to what I thought, parsing the DOM tree manually takes slightly more time than letting Dojo parse automatically while loading the document. A bunch of articles about Dojo are stil claiming that manual parsing is faster; however if you look closer, these articles are all about Dojo 0.4 (especially if they refer to "searchIds", now deprecated). Autoparsing has undergone many optimizations since then, and version 0.9 doesn't need such tricks anymore.


This post has been completed while listening to :

Don - Original Soundtrack
Don OST (Shankar Ehsaan Loy)

Wednesday 17 October 2007

Why Dojo ?

In the beginning was the demo... and as all demos fund-raising demos, it had to be sexy, get straight to the point and be quick to build.
As I needed "Web 2.0" javascript controls to put on these pages and impress the investors, I chose the Dojo framework.
Why Dojo ? Well, just because it was on the online press at the right moment, and I have to say their demo page was sexy and efficient at that time.

That was last year.

Now guess what ? I'm still sticking with the same javascript framework, which I recently migrated to its newest version.
Why Dojo, once again ? After the demo (which actually came along with a speech and a business plan), things went pretty fast and I found myself dealing with the real thing, with no extra time to spend on a javascript benchmark.
That said, I didn't even think of putting my choice into question - it was there and running, and everyone seemed pretty satisfied with it. Especially now that I've put more time into understanding the 0.9 architecture, I'm quite satisfied by my early choice.

So what's the point of this post ? When Dojo released their new online documentation - The Dojo Book - in September, I stumbled upon why Dojo ? and realized that the "race for production" I had been thrown into made me forget that there was something else than Dojo out there : not only the six major toolkits mentioned on the Dojo book, but also a couple others.
Seeing all these projects made me want to try more stuff, just to see how they would fit into our existing sites, if we wanted to replace Dojo by something else.

Anyway, since my boss would probably choke if I took our precious time to change something that already works, I'll just take a couple of hours here and there to see what each of them can do. Better to be aware than blinding oneself just because choices have already been made - at least that's true in the context of IT :)


This post has been completed while listening to :

Just One of Those Things
Just One of Those Things (Lionel Hampton & Oscar Peterson)