Reducing bandwidth usage?

Hi all,

I’m developing a Vaadin application for mobile devices, and I would like to reduce the bandwidth usage as much as possible to help with 3G connections.

The iPhone shows the amount of transfered data, and I can see that each connection to the application downloads more or less 220 KB, which is a lot. Subsequent events (clicks, tabs changes…) are quite fast. My entry page contains around 2.5 KB of images, so I guess most of the 220 KB comes from the widgetset.

I’ve tried the same thing on my desktop computer with Chrome, which shows file downloads and sizes, and it seems that the widgetset is cached and not downloaded at each new connection. According to Chrome, only 15 to 20KB are downloaded when connecting to the application, the rest comes from the cache.

So I’m not sure, but I suspect that Safari is simply not caching (at least) the widgetset. Any idea on this? Is there any way to force it to cache the widgetset?

BTW, a related question: Is it possible to build a custom widgetset containing only the code I actually need? I mean, I don’t use a lot of widgets in my application, so would it make sense to compile a widgetset excluding all the widgets I don’t use in my application to reduce the downloaded size?

You definitely want to leave out the widgets that you are not using from your widgetset. See
http://dev.vaadin.com/wiki/WidgetSet
. This should reduce the size of the widgetset considerably.

Also be sure to turn on http 1.1 compression from your application server - if it is not already.

Thanks for your advices!

I’ve tried to enable lazy loading, but that didn’t make any difference. I’ve then tried to compile only the widgets I need (still inheriting from the lazy loader), and the size of the widgetsets went from 3.3MB to 1.8MB. Now, according to the iPhone, only 125KB are downloaded when connecting.

Yep, was already turned on.

So that’s a total saving of almost 100KB for now. Any other thing I should try to look at?

The only reasonable path I can think of to go even more compact from there would be to tune the GWT compiler options. You could disable client side stack traces and maybe also cast checking. I suspect turning off class metadata (including Class.getName() etc.) would cause problems, but even that could be tested.

-XdisableCastChecking
-XdisableClassMetadata

See
the GWT dev guide
and
EmulateJsStack.gwt.xml
for a little more information.

Disclaimer: I have never tried these options, and they are not well documented. Some of the options are experimental, and could cause unexpected problems, both generally and specifically for Vaadin, so be sure to test their impact one by one and in combination. They probably will make debugging the client side harder.

Then again, I think correct caching would have a much bigger impact. Maybe someone else has an idea about that.

Thanks!

Removing stack traces seems to help a bit more, looks like the amount of transfered data is around 110 KB now. I’ve been playing a bit with the application and I didn’t find any problem caused by this, so I’ll keep an eye on it to see if strange things start happening.

I didn’t try the compiler flags, as I don’t know how to pass them to the Vaadin Eclipse plugin.

The Eclipse plugin does not support giving additional compiler flags, so you would need to do the widgetset compilation for the release build with some other build system.

I did a quite test with a widgetset that was very close to the default widgetset, disabling cast checking only reduced the (uncompressed) code size by something like 2% so I don’t think it is worth doing.