i install my page in tomcat server that i can download with 40k/s speed, the first load is too slow, in the firebug or google inspector this url take 14 seconds to download this url
VAADIN/widgetsets/com.vaadin.terminal.gwt.DefaultWidgetSet/F9A7C02EDAC9B699CDAACFD1E510FF5D.cache.html
even if my application contains a simple label to say hello, how to fix that
14 secs is really a lot. With 40k/sec it adds up to 560k. When I start hello world in demo.vaadin.com Firebug shows that it loads 551k from the net. So this matches. 427k of this is thejavascript and 116k is css.
BUT, firebug shows the size of the resources, not the number of bytes transferred over the wire. If your server is properly configured, it should use HTTP 1.1 compression for sending the resources. In compressed form the resources should sum to about 153k.
153k sent over your 40k/sec connection should take just 4 seconds.
In real life scenarios you will be also sending some images used by your theme, but still the “load time” of your application should fairly quick. And when the resources have been loaded once, only really small JSON snippets are sent - thus the application should be a lot faster than traditional “web 1.0” style application where full pages are sent over the wire all the time.
To find out more about configuring compression, see documentation of your servlet container. In case of Tomcat, see
http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
and parameters compressableMimeType and compression.
Thanks for you replay,
i activate the tomcat compression, i attach images that represent the firebug console, in the first request getvaadin it wait 4s, maybe cause i populate the selects with db infos, i ping the server with about time=150ms
If you’re performing lengthy initialization/data load operation in your windows/widgets, this may also cause longer delays in app loading. In this case Id recommend to move out all lengthy stuff from the window/widget constructor and invoke it in a separate thread with some king of progress monitor in UI.
Thanks for ur suggestion,
i think the latency is not only due to the db access, image for vaadim hello shows that slow, but i’m interest to load data in separate thread, have y ou an example to do that
It seems that you have not enabled compression for css (add it to list of compressed mime types). This could save you another 2-3 seconds.
Even better, if anyhow possible, would be to avoid any heavy initialization in the beginning and only initialize UI:s and resources lazily when needed. Otherwise you may end up consuming extra space from the HttpSession even for the users who doesn’t need that those UI:s/resources initialized.
With the above mentioned optimizations, it should be possible to get this time to 5-6 secs in your configuration. (latency adds some extra to the 4 secs I estimated above)
If this is still too slow, you could use a custom-made index.html page that could show something meaningful (instead of just “loading” animation) for the user while loading. This would not make start any faster, but user could is could feel a bit faster. Perception is everything ;)
Also, I thought I’d mention that it is possible to compile a custom widgetset with fewer widgets if you really must. I don’t actually recommend doing this, though, unless it’s really needed - it depends on the application whether or not the difference will be worth it, and it’s asking for trouble down the line (“oops, forgot to put DateField in the widgetset”).
Once GWT 2.0 is integrated we’ll probably be looking at using code splitting - specifically to speed up startup time and minimize the initial payload - a.k.a the “correct” solution. I don’t know if 6.3 will contain any built-in code splitting, but since it’ll be running GWT 2.0, it should be possible to do fairly easily (in fact, you could try compiling with GWT 2.0 and doing code splitting yourself, if you like - we did some tests, and it seems to work…)
Best Regards,
Marc