Steve Leland commented on Jul 7, 2009


You are correctly describing the reason for the Dojo architecture that Phil mentions. Rather than use <script src="your.js"> tags on your page, and incur the penalty you describe, the Dojo modules use dojo.require( "" ). This not only gives you nice encapsulation - much like #include in the 'C' world - but it also is the hook which lets the Dojo javascript runtime check to see if it has loaded anything that does a dojo.provide( "" ) - and only if it hasn't does it generate a request for a file like a script tag would: src="your/class/name". I would like to underscore Phil's announcement that this idea is being extended to css files as well in 8.5.1 - performance will continue to improve!!

Steve Leland commented on Jul 7, 2009


That series - Best Practices for Speeding Up Your Web Site - is excellent, and I think you'll find we found ways to implement something for most of the suggestions it offers.

The table reports on the count of requests between the browser and the Domino server to completely render the HTML page. Most of them have nothing to do with the 'monster' framework, thanks to the build process provided by the Dojo Toolkit.

Loading a cold browser cache is an area that could always use improvement - constructive suggestions are certainly welcome!

Tommy Valand commented on Jun 24, 2009


@Philipe: Your last statement is wrong.

For every file, the browser checks with the server to see if the file is updated/should be downloaded. A browser can only have open x amounts of "pipes" at a time, so this potentially blocks other downloads while checking. With 50-90 files, and high latency or low bandwidth, you -will- notice the delay.

I'm surprised/annoyed if you work on implementing XPages, and don't know this.

Philippe Riand commented on Jun 24, 2009

Decreasing the number of requests

This is a result of the Dojo module architecture. As Steve pointed out, this can be reduced by aggregating those files into bigger files. We are working on such optimization in 8.5.1. For example, we aggregated all the common UI related files in one single file. You should see noticeable improvements.

Now, all those files are cached by the browser, which means that the HTTP requests are only done the first time you access the page. Afterwards, the number of files doesn't really matters.

Mael Rivera commented on Jun 12, 2009

82 requests acceptable?

I believe not!

Goes against rule #1 of High Performance Web Sites: { Link }

Why IBM chose this kind of monster as a framework is beyond me.