This section touches on some of the low-hanging fruit that you can strive to achieve in your frontend engineering. For a fabulous reference on ways to improve performance, be sure to check out High Performance Web Sites: Essential Knowledge for Front-End Engineers by Steve Souders (O'Reilly). It's a quick read and really does live up to the "essential" part of the title. Much of the content is available at http://developer.yahoo.com/performance/rules.html.
- Dojo's build tools
- Lazy loading
While much has been said in this chapter on the virtues of using the build tools to create a minimal number of layer files for your application, there will certainly be times when it just makes more sense to do some lazy loading. For example, if you determine that users very infrequently make use of a particular feature that adds a nontrivial amount of script to your layer, you may just opt to
dojo.requireit on the fly instead of packaging it up.
Another consideration with respect to lazy loading is to intelligently use the layout widgets to load content on the fly. For example, you may choose to only initially load the visible tab of a
TabContainer, and either load the other content when it is requested, or wait long enough that you are certain the rest of the page has been loaded before fetching the other tabs. The
ContentPanedijit is a common vehicle for lazy-loading content.
- Web server configuration
Expiresheader; configure your server to take full advantage of common configuration options such as gzip compression.
- Maximize static content
Because static content can be served so quickly, the more of it you can serve, the less time your web server will spend per request. Maximize the use of static HTML files that are nearly identical by filling in the user-specific portions via cookies or XHR requests where possible. For example, if the only difference on a login page is a few hundred bytes of text containing some user-specific information, serve the page statically, and use script to asynchronously fetch the small bits that need to get filled in instead of dynamically generating the entire page.
You'll be able to host Dojo on a dedicated machine and share it amongst various applicationsâwhether or not they are on the same domain in your network.
dojo.requirestatements that happen when the page loads are satisfied asynchronously instead of synchronously (the case for a default build), which can improve page load times since the requests are nonblocking.
Some browsers, such as IE, limit you to two open connections per subdomain by default, so using an XDomain build essentially doubles the number of potential connections for your applicationâtwo for Dojo and two for everything else in the local domain.
If you serve multiple applications that all use the XDomain build, the overall HTTP latency your clients endure is likely decreased, as the overall amount of content that their browsers can cache locally is increased.
As a final word of caution, don't prematurely optimize your application; when you do optimize it, never do so blindly based on guessing games. Always use demonstrable information such as profiling information or server logs to your advantage. Particularly with respect to optimization, our instincts can often be deceived. And remember: Firebug is your friend.