On GI Performance Tuning
Performance is a big topic. A while ago I saw a blog on GI performance turning, see Sunil's blog, , which hits on some basic point of AJAX application optimization. The GI documentation also devotes two entire Chapters on this topic (Optimizing Application Performance and Optimizing Load Performance ). There's also a video tutorial on this Video 6: Optimize Performance. 
So, as you can see this is an important topic and a frequently asked question.
Basically there are 3 major type of performance issues that concerns GI application
1 Resource loading performance
2 HTML rendering time performance
3 Data parsing and handling
For the first type of issue, the answer in a nut shell is "asynchronous, asynchronous, asynchronous". However this very AJAX answer is not the whole picture.
One of the cited benefits of Ajax is that it provides instantaneous feedback to the user because it requests information asynchronously from the backend web server. However, using Ajax is no guarantee that the user won't be twiddling his thumbs waiting for those asynchronous JavaScript and XML responses to return. In many applications, whether or not the user is kept waiting depends on how Ajax is used. For example, in a web-based email client the user will be kept waiting for the results of an Ajax request to find all the email messages that match their search criteria. It's important to remember that "asynchronous" does not imply "instantaneous".
Before GI 3.6, XML resources on Internet Explorer are loaded by GI using native MSXML3 Document ActiveX object's load method, which is not same as XMLHTTPRequest object. From version GI 3.3 to 3.5, GI forces the use of cache XML when a cache copy is present and regardless of the HTTP cache control metadata( Understanding IE Caching and GI 3.3-3.5. ) This was done as a workaround for an IE6 defect. From GI 3.6 and later, GI uses the XMLHTTPRequest to load XML resource and thus subject to the same caching rules.
What is not known to some developer is that resouces loaded over HTTP are not cached by the browser if it is not properly configured, expiration time and HTTP cache control are key to the use of browser cache.
What is often forgotten is that regarless of whether your application is AJAX enabled or not, it is in the end still a web-based application. This means that the standard HTML page optimization techniques still applies. These are things like (as found by Yahoo performance team, these are my top 4):
1 Add Expires header (and or HTTP Cache control header)
2 Gzip components
3 Minify Javascript
4 Configure ETags
See the full list at Yahoo performance rules, and the Special Rule for AJAX Make AJAX Cacheable.
As for the last type of issue on Data handling, what is often forgotten by AJAX developers is that the browser (especially older browser like IE6) was never designed to run a full fledge application or handle hundreds of megs of data. So developer should remember to keep the heavy lifting on the server and allow the the client GI application to fetch only the neccessary data when it's needed.
Using hide / show, (setting "visibility")
One of the optimization technique I've seen for HTML rendering is to use the "Visibility" property. What the developer should know about this technique is that GI has a dual DOM architecture. This means that GI is architected to use a secondary abstraction DOM used to model and keep track of GI objects. So making the object "hidden" does not remove it from the GI DOM model. On top of that, while the HTML is not visibly rendered, they are still present in the HTML DOM, which means that any DOM operation on the element will still be affected. In short, this technique should not be applied blindly everywhere. A good example is the the Tab UI control which employs this technique to hide/show the tab panes. A bad example is where the application load every canvas in an application and hides them, regardless of whether the compnents/canvas will ever be shown.
