I hope we will improve the application itself (profile and fix using Firebug and SpeedTracer – other ideas are welcome) but we can also do other unrelated optimizations…
To reduce the number of round trips to the server, in addition to the good caching policy, we must take advantage of new GWT features, especially ClientBundle - this replaces ImageBundle.
A quick look at SpeedTracer shows GWT already optimizes 'png' into 'data:// ' stuff, which is embedded into the html:
It seems gif images are not inlined this way, yet. Maybe using ClientBundle instead of ImageBundle will solve this.
We should also take advantage of code splitting. It’s pretty easy to do – the complexity consists in identifying which parts can be run asynchronously. Probably the main page loaded after login and the main tabs “on click” handlers are good candidates.
For more info about all new features: http://timepedia.blogspot.com/2009/12/gwt-20-so-good-its-ridiculous.html. Interestingly, even if not related to optimization, the Ui Binder could help us if one day we decide to redesign the way the model entities are shared between the client and the server, and how the GUI is built.
The resources in a deployed GWT application can be roughly categorized into resources to never cache (.nocache.js), to cache forever (.cache.html), and everything else (myapp.css). Client Bundles allow you to move resources from the everything-else category into the cache-forever category.
The Lightweight Metrics system is a tool to find key areas where latency may be noticeable to your end users. It has very little overhead, can report metrics on application load time and RPC calls, you can profile multiple GWT modules at the same time, and can be extended for your own measurement needs. The Debug Panel for GWT uses the Lightweight metrics system. It provides an easy way to collect metrics and test your GWT application.
So, currently, IMHO, we’re using GWT 2.0 just as we were driving a Ferrari at 30mph :-)) Let's push on the gas...