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.
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).
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.
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.
