TVC Helium - Performance Guide

1. During development & before deployment

This section describes recommendations on how to configure the webapp server, TVC and its caching, as well as best approaches on how to modularize Helium views using the component building blocks.

1.1. Server configuration

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.
HTTP/2 will make our applications faster, simpler, and more robust and it also opens up a number of entirely new opportunities to optimize our applications and improve performance!

To enable http2 in your windows environment by adding below lines in apachefolder/conf/vhosts

    LoadModule http2_module modules/mod_http2.so
    <IfModule http2_module>
        ProtocolsHonorOrder On
        Protocols h2 h2c http/1.1
    </IfModule>

Also few good blogs which provide much more depth knowledge, can be followed by below links.

To take advandtage of HTTP/2 we can load the vendor files in split which helps us in decreasing the size network repsonse. this can be enabled by adding below line in tvc.property : ]

tvc.helium.isHttp2Enabled=true

1.2. tvc.properties

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.

1.3. Configuration guidelines

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.

1.4. Working with custom webapp files (JS, CSS and Handlebars)

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.

2. After deployment & analysis

Once the Helium webapp has been configured and customized, and deployed onto a server in production mode, you can use following tips and tricks to profile performance and identify bottlenecks.

2.1. Profiling with web browser, general

Regardless of which browser you use, the Developer tools is generally a helpful first starting point. Ensure that you have not activated "Disable caching" or throttling, if you are analyzing network traffic or performance. You must also avoid the incognito mode for reliable results, as it disables some core browser features in the interests of privacy.

You can typically understand using these tools whether your performance bottlenecks are in one of three main categories: waiting for server side code execution, awaiting network response, or on the browser side, parsing response/rendering the DOM.

There are even advanced features / standalone plugins such as Google’s Lighthouse or Yahoo’s YSlow that can provide a detailed report with best-practice webapp checklists - listing both passed audits and criteria, but more importantly, pointing out bottlenecks with specific detail.

2.2. Profiling server side execution bottlenecks

In the TVC Product portfolio, we have a specific admin tool for profiling your PLM system in general, and which also works with the TVC’s and TVC Helium. Using the Profiler, you can identify inefficient DataHandler Java classes, or heavy access checks. For more info, refer to the Profiler documentation on https://products.technia.com.

2.3. Check the console.logs

For some violations of best practices, browsers themselves are already throwing warnings in the browser console. For example, if your JS code is using deprecated ECMAScript API’s or if your server does not have a valid SSL certificate.

From TVC Helium, we will increasingly also print console warnings wherever applicable or helpful. For example, if your custom Widget type does not implement a destroyer() method, we will warn you that in the long run, this might leak memory. Or if you have mistakenly added two Widgets with the same ID in a Dashboard. It’s a good idea to keep an eye on the console, at least during the development phase.

2.4. Trial-and-error

If you are still uncertain on how to figure out where your bottleneck may lie, good old fashioned trial-and-error can still be useful. Try commenting out a Tab or a Widget at a time, and try disabling any custom postRender JS functions.