Table component performances

Hi all,

We are trying to migrate Echo2 based applications to the Vaadin framework, but we are encountering problems with the Table component’s performances on client side.

When the client’s computer is a little slow, the performances (especially under IE6) degrades to the point where the interface basically becomes unusable.

I am trying to reproduce the following table which contains components in almost all the columns :

Here is a basic reproduction of the table I made using Vaadin :

A lot of our users are using celeron based computers under windows XP, scrolling to view more data causes their browser to hang for around 5 seconds with this test program.
When the page length is increased to about a hundred rows, the loading freezes the browser for more than a minute.
The Echo2 table is also somehow slow on those computers too, but it is nothing compared to Vaadin (and as it is pageable, the users are more inclined to wait).
We set the cacheRate at 0.1 as higher values led to even worse performances

Does anyone has a clue or advice concerning those poor performances ?

Would table.
help at all?

Also - if nothing helps, you can always use GridLayout and add paging yourself. Here is
an example of a webshop that does just that

Another example from a web shop with Table:
can be found here by selecting car brand (merkki) and model (malli) and clicking “Selaa tuoteryhmittäin” (browser by category)
- categories can be selected from left.

Does these perform well enough with computer+browser you are targeting for?

One more idea on optimization idea.

If the performance is of when you remove the first column (one with CssLayout and buttons), you could try to optimize the whole thing my replacing the buttons and csslayout with a custom widget). The widget would be really simple to do - it just passes back two button clicks and the rendering could be anything that would be fast enough for IE6. This might also allow you to add some character to the website by creating a custom “shopping item control widget”. If you have not created custom widgets before, be not afraid - just click thought the eclipse wizard - it created an almost ready widget for you…


I quickly looked at your example. There is one quick and most likely quite effective optimization you could do (in addition to change your clients browser to this decade). There are several Label components in your table. Label’s default width is 100% which causes some extra work for browsers. Undefined width should be fine for you - and faster.

Of cause the best would be if you and render the content as raw text instead of using Label component. Too bad our column generator (that I guess you are using) don’t support this currently.


Thank you very much for your answers,

I did some tests with the different solutions you proposed :

  • The current table with the CssLayout+Labels on our target computer and with .setCacheRate(0.1) renders the 15 rows page in around 5 seconds
  • Removing the CssLayout and the Labels (leaving a single button per column) lowers the rendering time to around 3 seconds per loading request
  • After removing all the generated columns in the table, it took only 1.5 seconds per page
  • increasing cacheRate from 0.1 to 1.0 made the interface completely unusable (didn’t even measured the rendering time)

The grid layout seems like a good idea for the webshop’s main page, but the example I showed there is only the tip of the iceberg. There are a lot of applications here using tables with components inside, for example the whole webshop system’s interfaces are using around 50 different tables. (intranet applications to process the orders)

The wizard component creation is a nice feature :slight_smile: I tried it and the performances were almost those of the table without generated colums (I did not tried complex components though, only the one generated by eclipse).
But I feel it’s a bother to do that just to get simple buttons working faster (on the other hand, removing the CssLayout and putting the buttons in different individual columns would not be a problem).

Else I found this pagedTable on the forum (unfortunately no source code was attached) :

Even if the rendering was slow, users would not complain because they are psychologically prepared to wait after an action.
I wonder how the author of this example got this working

If I was god, I would kill internet explorer :rolleyes: .
Unfortunately, around 80% of our visitors and customers are still using IE ; IE6 alone accounts for 40% of the traffic (companies here still use it a lot)


Rule of thumbs if you need to support IE6 with large Table:

  • avoid relative sizes for components inside Table, especially note the default width of Label (100%)
  • favor raw text content instead of components (including Label)
  • try to render the Table to a short component tree (not inside complex layout)
  • minimize cache row usage
  • also check the time consumed by the server rendering the response (in your example about second from our office)

See also:


Hi Kevin!

I’m the one that had created the pagedTable that you linked to. Unfortunately, I don’t have the source left for that demo. Fortunately, I decided to create it as a Vaadin add-on. It can be found at
Vaadin Directory