Client side code size?


lets speak about Vaadin 6.3.2.

Does anybody knows what is client-side size that is downloaded by the browser?

How much of code is nesessary downloaded by the first time and how much can be downloaded later?


Just checked the HelloWorld demo (which contains the DefaultWidgetset), and the whole download size is just a little over 500kB.

About the initial download: currently, all the client side code is downloaded immediately. Since GWT previously only allowed to generate one monolithic JS file, that’s what where using. Since GWT 2.0, there is a new code splitting feature allowing to split the client code into smaller bits that are downloaded only when needed.

We’ve yet to have a good look at how this might fit in with Vaadin. Any experiments and feedback on this are welcome, if someone has the time to dive into that…

Thank you,

I am looking forward to see code spliting in action :):).

And two more questions.

Does those 500 KB are somehow cached so when I will be back on this site and there were no changes then it will be taken from cache?

How can we reduce those 500KB?? One thing is to switch on http compression but are there more ways??


Hi Jouni,

Are you sure about the 500kb? shows that the defaultwidgetset.js is only 2.2kb. I ran firebug. Maybe the gwt 2.x compiler optimized it further.


This file is only main code loader: GWT compiler produces 5-6 files for each browser and this loader detects client browser and loads specific main file compiled for this browser, e.g. 7D252B91A76876C866BA54FF550DAEDD.cache.html (which is 500kb size)

Also note that web server uses compression for sending the code. Compressed JavaScript code is actually 153kb.

It is cached by the browser

Thanks for the answers.

Do we talk about http compression or there is one more compression mechanism??

Just normal http compression.


As Joonas already told setting compression on in the server is the trick number one. JavaScript code in general gets compressed very well with gzip and the CPU penalty is pretty minimal. Just make sure your server compresses especially those *.cache.html files generated by GWT that contain the actual JS code. Also CSS files in Vaadin are quite heavy weight so I suggest compressing them too. However compressing image files makes no sense as they are already compressed.

To reduce the JS size further we have two practical tricks. The first one is applicable today, for the latter you need a custom build of Vaadin.

Trick #2: limit client widget implementation in the default widgetset

If you are using just a small portion of widgets in you application, this may reduce the compiler JS size significantly. The trick utilizes GWT generators, it is not just simple Java coding and is no means supported by Vaadin. But it is no rocket science either. We use GWT generator to connect client and server side implementations, based on @ClientWidget annotation. By overriding one method from the generator, it is possible to leave out those widget that you know you don’t need.

Start by adding following instruction to you .gwt.xml file (aka widgetset GWT module)


<generate-with class="com.myproject.MyWidgetMapGenerator">
	<when-type-is class="com.vaadin.terminal.gwt.client.WidgetMap"/>


Then implement com.myproject.MyWidgetMapGenerator class that extends com.vaadin.terminal.gwt.widgetsetutils.WidgetMapGenerator class. Override its getUsedPaintables method and return only those server side components that you wish to support in your optimized widgetset.

Tric #3: Start using code splitting today

There is a patch waiting for testing and stabilization in trac:

Don’t know when we’ll find out time to include it in to release. If you and others find this essential, its priority of course increases, but we haven’t seen this too big issue yet. Emerging web app usage from devices like iphone and slower internet connections of course increases the importance.


Some more info on widgetsets and code splitting can be found at