TVC Helium - Performance Guide

Ensure your server and TVC is running in production mode. This will significantly reduce the number of network requests needed, as Helium will request concatenated, minified JS and CSS files. Production mode will also remove excess logging, ensure caching is utilized and other performance related optimizations.

Enable compression (e.g. gzip or Brotli), especially verify for mimetype application/json which may not be included by default.

Verify that no servlet filter, load balancer or other mechanism is setting Cache-Control headers that break the intended caching.

For modern browsers, TVC Helium leverages a Service Worker to cache static resources as well as some service calls. The behaviour of what to cache can be controlled in detail via a set of several tvc.properties.

It is recommended to enable Helium’s end-user customization features for e.g. Tabs and Dashboards. Doing so enables each end user to for example close Tabs and Widgets that they are not interested in, also persisting these customizations for subsequent page visits, where this will save on network transfer times.

Consider <Access> checks and whether you really need them. Access checks are blocking logic performed on the server side, which means that during the evaluation time, they will delay the response back to the browser. As an example, you can consider having two versions of a Page, which only requires one access check, as opposed to setting access checks on each Widget.

A rough guideline for TableWidget can be that if you expect more than 500 - 1,000 rows to be returned, it may be better to opt for server side processing and only evaluating the current table page. See the ending part of the TableConfig settings.

As a rule of thumb, try to avoid having too many Widgets in the same Dashboard. If possible, try to group views into Tabs and/or using the Sidepanel Dashboard concept. It’s much quicker to load smaller dashboards, instead of navigating between full Pages.

Similarly, consider using ToggleWidget functionality to swap a widget for another when applicable. For instance, load a "light" version of a table with 5 columns at first, and allow the end user to toggle to the "full" table version with 10 columns on request. Their choice will be persisted and remain for subsequent page loads.

Finally, be wary of using the <CacheBehaviour>preload</CacheBehaviour> setting for Tabs. It will incur background network requests that are invisible to the user, still slowing down the load time of the actual visible tab - so only use it if you are pretty sure the user is going to navigate to the sibling tab later on.

We recommend bundling and minifying your custom JS and CSS files, respectively, into one file of each type. Not only will this save network round-trip time, but having fewer CSS files also avoids blocking the DOM rendering.

For Handlebars templates, it’s preferred to precompile them into a single JS file. This will not only avoid synchronous network requests to fetch .handlebars files, but it will also save on rendering time. Consider precompilation of Handlebars templates to be a one-time server side task, rather than each browser having to do it.

Images can utilize the Semantic UI feature to lazy load images only when they are scrolled into view.

You are very welcome to deploy the Hex or Launch Pad configuration packages, but make sure to delete any unused example JS, CSS and .handlebars files before deploying to production server, to avoid unnecessary network transfers.