we developed our application with the latest vaadin (6.3.2) very very quickly. This is really nice!
But we have relative long load times >2seconds. Escpecially firefox >=3.5 with >4sec (under various OS’s) is a problem. I see the same lengthy load in this vaadin application: http://www.blackbeltfactory.com/ui
BTW: Is vaadin.com made with vaadin? If, yes. How did you make it so fast?
Another problem is that an action which changes a lot of the site, again takes over 2sec (again firefox is even slower).
Our questions are:
How can we make it faster? Should I use customlayout instead nesting several grid, vertical or horizontallayouts?
We profiled the application while the site changes and see a lot of AbstractComponent.paint, gridlayout.paintcontent and abstractorderedlayout.paintcontent calls. But how can we determine which gridlayout and which component is the reason? Any tips?
Hi Peter,
Maybe you could activate compression in you application server. For example in Tomcat embedded this is done by this:
IntrospectionUtils.setProperty(connector, “compression”, “force”);
For a normal Tomcat (not embedded) take a look at
Tomcat 6 documentation and the “compression” directive.
That have a real success for me. There is a thread that have already disccussed about it maybe there will be ohter useful information
Hope it helps
Regards
Yves
Please do a comparison to load time with
a simple Vaadin app . If even this simple Vaadin app loads slowly, then the cause is size of the widgetset.
Optimization info
Try to avoid having huge or deeply nested Horizontal, Vertical and GridLayouts if there is no absolute need for them. CssLayout could be a better alternative. Also check
FastLayouts and
DashLayout .
How much could this improve startup loading? And when do I know that I use a widgets? So far we only use layouts, buttons, labels, checkboxes + links
One question remains: how can I can profile the UI of a vaadin application (e.g. to replace only the necessary horizontallayouts with your suggested FastLayout etc) ?
Leaving out table, tree and similar components could squeeze out perhaps 20-40% of the widgetset size. However, much of the widgetset size comes from common libraries and utilities (including standard JRE) used by many classes, so leaving out a simple component might have almost no effect.
Unfortunately, true profiling is very hard. Not only is the render time of a component very much dependent on the context in which it is (layout/DOM hierarchy), but also the inter-thread interactions within the browser etc. play a significant role.
One rough approach would be to use the “?debug” URL parameter and see the render times on multiple repeated runs, taking an average of runs after the first one or two where the cache is populated. Also trying to just leave out one component/part of the UI and re-running similar profiling would help isolate the effects of that part, but possibly only in that context.
FastLayout was the predecessor of CssLayout, I would recommend using DashLayout or CssLayout instead. HorizontalLayout and VerticalLayout, despite their apparent simplicity, are actually quite complicated and costly, especially when deeply nested.
Some UI optimization hints can be found e.g.
here .
Peter, it would be great to hear more about your conclusions on this performance issue. Could you elaborate a bit to let everyone learn from your experience.