Not every application is the same, and Dojo's package and build tools let you mix and match in order to handle these variations. In many cases, you may be able to use one of the "off the shelf" builds in order to test the performance differences.

If you've done testing and are certain that a custom build is the right soltuion for you, or you are just curious about what is happening, then the first step is to decide what modules to include in your build. All of the files from the modules you specify and their dependencies will be included in the resulting dojo.js file. It's best to start with the modules that you know are used in every page of your application, or at least the majority of them. This will be your base profile, and all of these modules will be compressed into a single file that you will specify on your HTML page.

Creating this profile is a soft science, because loading files later means that they are less compressed and the total download size of your application increases, as well as the number of files that need to be loaded later on. But this compromise means that if there are infrequently used parts of your application, the average user will have a smaller download. Also, if getting to various stages of your application happens over a long period of time, these modules might be better left out of your profile as well. The package system can be used to opportunistically load as well as optimistically load resources. Here's where tools can help sort out what's best.

Since Dojo package and resource loading generally happens via XMLHTTP requests, tools like Firebug's network visualization to determine which files are getting requested at runtime from Dojo. See the section on Profiling JavaScript for more tips on how to determine what should be included in your distribution. A poorly constructed build, or no build at all, tends to show a cascade of requests that are very clearly serialized. By noting the namespaces that are being requested and then adding them to the profile, you can construct builds that meet the needs of users and defer work until it's really necessary.

For example, if a user has to go through a log in screen before he or she is taken to the next page, it might be worth waiting for a successful log in before loading additional modules.