I met a customer at W-JAX who had a performance issue with one of their screens. They were rendering a huge 90-column and around 1000-row TreeGrid on that screen. The screen was a preview for a database query that would ultimately be downloaded as a file for further analysis in another software.
TreeGrid, in the latest Vaadin versions, has had its performance issues, some tackled and some that we are still investigating. While Grid (and TreeGrid) lazy loads the rows, the large number of columns may slow the browser down. Please note that there is an enhancement issue and even an early prototype for horizontal virtual scrolling. The use case is still valid, and I wanted to look into workarounds. Even if you wouldn’t have this kind of monster view, my investigation's results might help you optimize some other views.
Method 1: Grid
Grid is one of Vaadin's most powerful basic components. It helps lazy load large data structures on two levels: automatically between the client and the server and, with a little help from you, also between your backend/database and the server. A large grid, like one with 90 columns, may take a bit of time for the browser to render (~ 800ms in my test case) as the client-server lazy loading works only vertically (row basis), but it doesn’t really matter if you have 1000 or 100 000 rows (9 million cells).
Developer simplicity: ****
Server CPU time: *****
Browser rendering time: ****
Transferred data: *****
Method 2: TreeGrid
TreeGrid is an extension to the more commonly used Grid component. It provides an API to show a collapsible tree structure of the data. The downside is that the API becomes more complex, and also both the server and the browser need to work harder to show the data. Rendering time on the browser is roughly double compared to a plain Grid.
Developer simplicity: ***
Server CPU time: ****
Browser rendering time: ***
Transferred data: *****
Method 3: Raw Vaadin components
Rendering huge component sets directly using Vaadin components is certainly possible, but not a very good usage of resources. For testing purposes, I used an add-on that wraps the HTML table, <tr>, and <td> elements and rendered the same data set. While performing this is straightforward and as flexible as it can be, thanks to the simple Java API, it definitely utilizes a lot of memory, sucks up network traffic, and crashes the browser. For my Safari, it took ~ 5 seconds to render the page, while Chrome, which seems to be the slowest one of the modern mainstream browser engines, simply dies under the load.
If you need hierarchy, that is possible with TreeGrid; you can implement that with some CSS and buttons assigned to the first column.
Developer simplicity: *****
Server CPU time: ***
Browser rendering time: *
Transferred data: *
Method 4: HTML component
A better approach is to use the built-in HTML component. While the component still parses the whole HTML using the Jsoup library (sanity & security), it doesn’t store and transfer each and every element of the HTML snippet as “flow elements,” but most of the content is transferred as raw HTML. This is easy for both the server and the browser (renders in less than 500ms), and if you have the gzip compression turned on within your server, the transferred amount of bytes is also decent.
The downside of the approach is flexibility and developer simplicity. To change the styles, you'll need to work with raw HTML and perhaps some CSS. And HTML is all you can use. You provide the structure Vaadin components when using any of the other methods.
Like in the previous step, displaying the data hierarchy is possible with CSS, but making the hierarchy collapsible also requires some JavaScript expertise.
Developer simplicity: ***
Server CPU time: ****
Browser rendering time: ****
Transferred data: *****
Method 5: Raw HTML using CustomLayout component (add-on)
This last method is by no means the least. CustomLayout component supercharges the well-performing Html method discussed before but adds some flexibility by adding component support to it. This method allows you to add a variety of action buttons to each data row, for example. Even with 1000 rows and one more button, the rendering time is still considerably below a second.
The add-on does absolutely nothing to your HTML before passing it to the browser, which makes the server-side perform still faster than the built-in HTML component. But be sure not to pass non-trusted HTML to this component!
The downside of the approach is the same as in the previous one; most of the actual payload must be expressed with raw HTML.
Developer simplicity: ***
Server CPU time: *****
Browser rendering time: *****
Transferred data: *****
Final thoughts
The best options for rendering huge datasets, both on the client and server sides, are certainly Grid and TreeGrid. The amount of rows doesn't substantially affect their performance figures because of their slow-loading characteristics. Although a huge number of columns may bring browsers to their knees, consider making seldom-used data default-hidden.
For a “medium-large” static report view, it may be better to use raw HTML to format the results. Even large datasets can be surprisingly easy for both client and the server. Solutions scale linearly in both axes, so a large number of columns shouldn’t pose an issue, but the size of the dataset will have its limits. If you need the best possible performance or to place some Vaadin components to this kind of static HTML report, check the CustomLayout component from the Viritin add-on.
New to Vaadin? Get a feel for what you can build with Vaadin and start a new project at start.vaadin.com