In my last dojo app, I only used a few controls and as such performance was 'good enough'. However, it was niggling me that I should look into the dojo custom build system. I'm currently building a new audit and I need to use additional controls. It was enough of a reason for me to take a peek.
The two things that I wanted to find out were;
- How easy is the dojo custom build system ?
- How much difference will this make to the performance ?
The Dojo Build System - Creating your own custom build.
As Tim has already blogged about, using Dojo in its vanilla state means that you will have a whole bunch of seperate HTTP requests - which affects performance. In addition, the files haven't been optimized for downloading quickly. The dojo build system optimise the files by interning, removing whitespace, removing some comments, shortens variable names and rationalising the dojo layers.
I was quite surprised just how easy the build system was to set up and use. Here is what to do.
1. Download the source code files - I used the dojo-release-1.2.2-src.zip
2. You then need to create a profile. This tells the build system what bits of dojo you use. Its pretty much the dojo.requires entries. This is what my scius-profile.js looks like and you need to put this in the util\buildscripts directory.
dependencies = {
layers: [ {
name: "scius-dojo.js",
dependencies: [
"dojo.parser",
"dijit.Dialog",
"dijit.form.Button",
"dijit.form.DateTextBox",
"dijit.form.NumberTextBox",
"dijit.form.CheckBox",
"dijit.ProgressBar",
"dijit.layout.ContentPane",
"dijit.layout.StackContainer"
] },
],
prefixes: [ [ "dijit", "../dijit" ], [ "dojox", "../dojox" ] ] }
3. You then need to run the build script, you can do this from the command line - or from a batch file in the buildscript directory. My scius-build.bat looks like this
build.bat
profile=scius
action=release
profileFile=scius-profile.js
releaseName=scius-dojo-122
optimize=shrinksafe
layerOptimize=shrinksafe
copyTests=false
localeList=en,en-us,en-au
I've chosen to use the dojo version in my release, so that I can keep track of which dojo version it contains (you can also include your own version attributes). I've also decided to use a custom list of locales rather than the default, the audit is only available to Australians, so I wanted to cover most language settings that might be used.
After about 85 seconds, the build system is finished and you then have your own custom build waiting for you in the release directory.
How to use the custom build in your page ?
Now that you have your own compacted build you'll need to use it in your web app. In your pages that use dojo, you will need to update the dojo references to the new build and also include a reference to your custom build js.
I update the head tags to include /dojo/scius-dojo.js as well as the reference to the /dojo/dojo.js. My new script links look like this;
<script type="text/javascript" src="https://website/scius-dojo-122/dojo/dojo.js" djconfig="isDebug: false, parseOnLoad: true"></script>
<script type="text/javascript" src="https://website/scius-dojo-122/dojo/scius-dojo.js"></script>
When the pages loaded, the number of http requests is reduced from 80 to 59 requests and even though the number of Kb increased, this changed the initial load time from 12.98 seconds to 4.21 seconds and the cached time from 6.98 to 2.185.
Where should I store the dojo files ?You may have noticed that the path to the dojo files did not include a database. That's right, I've placed the files directly under the servers data directory. On my linux server that is /local/notesdata/domino/html/scius-dojo-122. Putting commonly used web files under the html directory is a well known performance technique. However, sometimes it's not always possible or desirable. For example, I'm quite happy to put my compacted versions of the standard dojo implementation there as I don't have a lot of applications or dojo variations to manage. I also have easy access. If you want out-and-out performance, that's the way to go.
Can you reduce the number of requests further ?
Maybe not for the original request but for further requests, yes you can. You need to set the expires header. If you follow the teachings of Yahoo, YSlow will give you a report on the files that don't have the expires headers set. Chris Linfoot and Chris Brandlehner have both blogged about setting the expires header for domino applications in more detail.
So exactly how do you do that ? It's a server config thing. You can specify rules for a website where domino will set the expires date. I set mine to cache any of my database theme files, all the scius dojo files and one rogue js file in the design. Just remember, don't set this as a global setting - it's a bad idea.
So now, subsequent page loads are very snappy. Down from 2.1 to under 1 second. You can see for the subsequent load only the html is needed. Everything else has been cached. 515kb to 39k and 59 requests down to 1 request.
Of course, YSlow is still give me rating of F. I still need to move CSS at the top, GZip my files, use a CDN and reduce the initial number of HTTP requests. However, now that the page loads have been reduced, I'm not going to sweat it.;-)
Of course, the last bit is reducing the time taken to download the HTML. If your application generates this dynamically through agents, views or forms, and it's this part that takes a long time, then you might need to consider performance improvements in the Notes application too.
Summary.
Was the custom build system easy to use ?
Yes. It didn't take too long to figure out my profile. Running a batch file and copying a directory doesn't take much effort either. Heck, you could probably automate that whole thing with ANT, including copying the custom build to your server by FTP - if you really wanted to.
How much difference did this make to performance ?
Using a custom build reduced both the initial and cached load time by half, setting the expires date reduced the cached loaded page by half again.
It terms of effort versus gain, it's well worth using the dojo custom build, maybe not for development. Maybe as a last step before promoting your application into your test and production environments.
Additional Notes about the Set up:
The environment I used was my development 8.0 server, running in a bridged VM with 512mb ram. The browser is on the host machine. I've noted in the past that this is slower than the response time I get on my production servers. However, it's a good control environment.
Thanks for the post.
ReplyDelete