Dojo in XPages – 4: Performance Considerations when Choosing a Module Loading Style

In the last post, I demonstrated different ways to load dojo modules in order to make them available to use on your XPage or Custom Control. A comment on that post from Richard Moy got me thinking about the performance implications of each method, so I did some testing. In this post, I’ll show the effect of AMD-style loading versus including the module as a page resource.

Dojo in XPages Series

Dojo in XPages — All Blog Posts

For the purpose of testing the difference, I created an XPage with a single button that uses dojo.fx.slideTo() to move the button because I know that dojo.fx is not automatically included on the page. In order to see the difference, I created one version of the page that loads dojo.fx as a page-level resource and another version of the page that loads uses AMD-style loading directly within the button code. I then loaded the pages and monitored the network activity with Chrome’s dev tools.

@Iq.js

@Iq.js is a file that contains aggregated JavaScript for an XPage. Since some dojo modules are automatically included on the page, it specifies those modules.

On the page that loads dojo.fx with AMD, this file was 17.4kb.

On the page that loads dojo.fx as a page-level resource, this file was 19.3kb. When looking at the file in the dev tools, I can see that it includes dojo.fx. Because I specified it as a page-level resource, it included it with the other JavaScript loaded on the page.

Here’s a snippet of @Iq.js on the page that includes dojo.fx as a page resource (with most of the code trimmed out).

/* XPages Aggregated JavaScript */
require({cache:{
'dojo/fx/Toggler':function(){
//>>built
define("dojo/fx/Toggler",...

'dojo/fx':function(){
//>>built
define("dojo/fx",...

'dojo/i18n':function(){
//>>built
define("dojo/i18n",...

'dojo/string':function(){
//>>built
define("dojo/string",...

...

AMD Loading

In my testing, AMD loading proved to be true to it’s name, loading the dojo.fx module asynchronously (as opposed to during the initial page load, mixed in with @Iq.js).

Dojo_4_FX AMD 1

It was not included on the page until the moment that the button was clicked, at which point, two more GET requests were made and the additional files were loaded.

Dojo_4_FX AMD 2

My Observations

After the module is loaded asynchronously, it appeared to be cached for the remainder of the browser session (although I did not test this extensively).

The AMD style of loading has the benefit of trimming the initial load time, but it then has to perform the load at the time an action is clicked. Theoretically, this will slow down the action to some extent, but that difference is imperceptible when testing the asynchronous load of a single small module on a local development server.

I don’t think there’s one always-right approach; it depends on the needs of your application. If initial load time is the top priority, then AMD loading will help in that respect. If page load time is plenty fast and you’re more concerned either responsiveness at the time an action is clicked or about maintenance of the code being a little simpler (especially when using the same modules in several places on the same page), then it seems to me that the code can be a little cleaner by loading the required module(s) at the page (or theme) level.

Advertisements

One response to “Dojo in XPages – 4: Performance Considerations when Choosing a Module Loading Style”

  1. Richard Moy says :

    Brad, thanks testing it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: