Rendering a large number of widget is very slow

we have encountered a problem while rendering a large number of widgets on one page. We have created a kind of demo application to test the rendering possibilities of Vaadin. We simple created a simple form with two TextFields, one DateField, one ComboBox and two Buttons and add this form a hundred times to Panel which is on application’s main Window. Rendering this page on Chrome/Safari took ~20 seconds. In IE the rendering fails completely and in Firefox you get the dialog with warning that script is unresponsive and you have the options to abort or to continue. If you confirm that you want to continue for about four times the page will finally render (after ~60 seconds), but you know, this is useless for potential customers.
Is there any reason, why the rendering of a large number of widgets is to slow using Vaadin? (Normally this number of widgets (approx. 600) on one page using standard HTML/XHTML tags is not a problem for any browser…)

Many thanks,

Yes, the rendering speed in Vaadin is not always so great if the UI is very complex. Vaadin has a lot deeper div structure than pure (X)HTML would have. Many of the core components have some extra wrapping over the native components, and the native components are not always used (for example Button vs NativeButton, etc).

Vaadin also makes a lot of calculations when rendering the page, for example calculating the component widths and fitting them properly with layouts, even though you might expect that such matters are the responsibility of the browser. As far as I know, this is largely because of browser compatibility; for example IE6 has some problematic limitations that have to be worked around programmatically.

If performance is an issue, you should use light-weight components and solutions in the application. The CssLayout is fastest of the layouts and doesn’t do any heavy calculations, also see the FastLayout add-on. Using NativeButton and NativeSelect components is probably a bit faster than the non-native ones. Relative sizes and expand ratios probably also have an impact; use fixed sizes if possible.

Then there are the occasional performance bugs.

While we do benchmarking and profiling of rendering speed, there’s definite need to develop it further. If you find any big performance bottlenecks, please report them with a ticket (or on the forum), and also submit the test code so that we can look into it.


In Vaadin building the html DOM is done in browser instead of just parsing ready html document. So I’m sure a plain html containing similar components would be faster to render.

As explained by Marko, Vaadin also builds a rather complex DOM structure to support a huge amount of features and to provide a cross browser support.

Luckily I have not seen a real application requiring to display 100 forms on a single view. With Vaadin you can easily build a “paging” for you demo, making it snappy to render and still easy to switch to the desired view.

You might also want to check out this wiki page: Sluggish UI


Layouts usually adds a huge amount of slowness in such situations - this is because most built-in Vaadin layouts performs some intelligent computations for every component inside in order to layout them all correctly.

The common slowdown demo is when you’re adding a lot of components to a VerticalLayout / HoriozntalLayout. If you’re adding to a Panel, it’s default layout is also a VerticalLayout one…

So, to optimize things you can go in the following ways:

a) Use CssLayout instead - it does not perform any computations and will render much faster being filled with a lot of components

b) Use a Table component instead of Layout and generated column as a single column in that table. The generated column component will represent a single row ( item) like in a VerticalLayout. As Table uses the lazy loading mechanism, you can have millions of rows with no performance degradation. This way Im displaying, for example, a book in TPT’s pdf viewer ( see a
of a