Unfortunately, in the browser environment, downloading many small resources can be expensive in time--particularly if those resources are downloaded synchronously and/or XHR is used as the mechanism to effect the downloads. The best solution is to download resources asynchronously and use script elements. This allows the browser to request several resources in parallel, dramatically decreasing download time, and thereby minimizing any perceived degradation in load time.
The following table summarizes that actual performance of bdLoad compared to the standard dojo synchronous loader. The first example simply loads dojo.js--the base dojo module. The second example loads all modules in dojo (a total of 64 modules). For all tests, the client was a Firefox 3.6 browser on Windows XP on VMware 7.1, and the server was lighttpd 1.4.28 on FreeBSD 8.1 on VMware 7.1. Both client and server were on the same machine so latency was well less than 1ms. This represents a standard development environment. The cache was disabled in Firefox as would be the normal case during development. The times were averaged over several sequential tests with the first test discarded to eliminate any server caching effects.
|Test Description||sync load
|Load the dojo module.||1.36ms||0.51ms||2.67X||try it||try it|
|Load all dojo modules (64 modules).||6.26ms||1.65ms||3.79X||try it||try it|
Note: the dojo modules have not been modified in any way. Though not officially supported, as of version 1.6, all dojo a dijit modules are compliant with the AMD specification.
When you try these over the Internet, download will be slower. Of course you won't be doing primary development over the Internet.
Also, while you have the debugger open, reload the AMD version of the first example. Now go to the network panel and notice the high degree of parallelism. You should see something like this:
Next, try the sync version and look at the network panel. Notice the sequential nature of the downloads:
Just for fun, we converted a couple of dijit tests to work with bdLoad. Notice that when you select the bdLoad version, the application provides near-instant feedback (that is, progressive enhancement works much better) and the application loads much faster; conversely, the synchronous loader results in a noticeable pause followed by an instant flash to the final application.
|try it||try it||Demonstrates the dijit calendar widget.|
|try it||try it||Demonstrates the dijit color palette widget.|
These are demonstrations of non-built versions of these applications (that is, the same thing you would use when you are developing). That means there are lots of individual resources that are downloaded and this takes time even with the asynchronous loader. However, when you're doing your own development, you'll be using a local http server and the delay caused by latency and bandwidth tends to zero. Notice, however, even with all these resources, the apps load reasonably quickly--particularly in Safari and Chrome.
It's important to note that the dojo cross-domain loader is as fast as an AMD loader; however, in order to use the cross-domain loader, you must execute a time-consuming build. Also, the cross-domain loader does not understand the AMD module format. If you have caching enabled, you'll see less (but not zero) difference on subsequent reloads, but you won't have caching enabled when your developing so this isn't relevant when evaluating the performance of the system for development.
Finally, the point of this discussion is show the incredible speed-up in load times during development that bdLoad can provide. Since bdLoad is the smallest AMD loader available today, it is equally impressive when it comes time to deploy your application. Here is a demonstration of bdLoad's tiny footprint.