My website is about 1MB and takes about 20 secs to download on empty cache. Out of which about .6MB is used to download SmartGWT js files like ISC_Core.js etc.
I am planning to write a maven task to combine the generated javascript files into 1 file and minify the resultant javascript.
Similarly for the skin styles.js and css files.
Does anyone done this? Any problems faced in doing so? Also, what plugin did you use?
One another note, when will we have SmartGWT using image sprites?
Anyone looking into this? I would love to throw everything into one JS file as well (so I don’t have to make 10 connections to get everything).
Just using closure compiler to combine things, and then gzipping, I saw the total size decrease from ~800kb to ~600kb. Assuming the user is on a 1mbps connection, that’s 1.5 seconds less to download.
Couple that with the fact that you free up connections to grab other site resources and I see this as a decent win (for very little work).
Parallel connections to grab the different files can actually be a net gain in many environments.
Interesting result with the clojure compiler, but the question is, does it still work? 
Clojure does some optimizations that aren’t necessarily safe for arbitrary code.
I would point you to this
Essentially it boils down to this. Pretty much every major browser supports a maximum of 6 parallel connections to one host so downloading a bunch of stuff in parallel has somewhat limited benefit. Once those six slots are filled, other request have to wait for one request to finish. This involves the entire round trip communication delay time for the sender to acknowledge that everything arrived hunky dory. (So, if your client has a ping of 200ms, it means that you have to wait at least 200ms for the next thing to start downloading in parallel).
Not only that, but TCP has a warmup that it does, so the brand new connections don’t initially start at full speed.
Of course, with things like SPDY, this is a non issue, sadly SPDY isn’t universally available.
So to the crux of the matter. SmartGWT requires at least 8 core files before anything can start happening. 2 more than the max parallel download connections. That means that whatever the user’s latency is, that time will be added to the total download time. Couple that with on site requests that have to happen (css, custom javascript, etc) and you could see why this might be an issue.
Sadly, I haven’t been able to deploy and test to see if it actually works. Google’s Closure is usually pretty safe so long as you don’t use advanced optimizations. Honestly, I think most of the size decrease came from it being one big gzip file. I’ll report back if this thing actually works
We’re aware of all of this.
What we’re saying is that using all available connections to pull down the .js is often the fastest way to get it, as opposed to using just one connection while the others pull down resources that won’t be required for the page to start appearing.
Also, the number of modules loaded depends on the features used.
There’s nothing stopping you from using the *NoScript variations of the GWT modules to allow you to combine files yourself if you want to, for instance, end up with exactly 6 files.
We’re pretty sure Closure must have broken the code to get those reductions (possibly in a subtle way, such as reducing the utility of stack traces).
However, bigger picture:
this is not an important optimization in the types of apps SmartGWT targets, because this download happens once ever per user, and SmartGWT is designed for apps that users revisit and use for long sessions
if you are really concerned about first-ever load performance, background download of the JS runtime is a much, much bigger benefit that any network-level tweaking - see FileLoader