A digital dashboard transforms raw data from different data sources into meaningful visualizations that give insight into that data. End users are always focused on those insights and how fast the interface rendered those visualizations, not thinking about the technical computations taking place behind the scenes. Thus, the quality visualizations and their rendering speed play significant roles in the value of any digital dashboard.
With our latest release updates for our Bold BI Enterprise (v2.8.14) and Cloud (v2.8.15) editions, we enabled vertical scrolling in dashboards. Dashboards can be vertically extended by increasing the number of rows to accommodate more widgets. Obviously, this will affect the dashboard loading performance.
Dashboard rendering speed, in general, not only depends on the scripts and internal computation speed, but also on the data server storage capacity and configuration from which the data is being read. In our previous blog, we discussed how to improve dashboard performance by optimizing data access. In this blog, I’m going to discuss the performance improvement we made in Bold BI through optimizations handled in scripts and internal processing, thus reducing the dashboard loading time by 50%.
Following are the optimizations we made to improve the loading performance of dashboards that will be covered in this blog:
- Load only what is required.
- First things first.
- Independent requests for widgets data.
Load only what is needed
It is thanks to the custom script generator that we’ve reduced the script size during initial page loads. With it, we load only the required script files for widgets in the dashboard now.
First things first
Instead of loading all the DOM when the dashboard is rendering, DOM required only after dashboard has rendered will load then. We’ve also optimized the CSS and script file size by setting those files required only after the dashboard renders to load later.
Independent requests and no more waiting for others
Now each widget in a dashboard will fetch data and start rendering independently without waiting for others to complete. Widget loading is now like the single-rider line in an amusement park: it doesn’t care about friends and family riding together, just completing the ride as soon as possible.
- We optimized the SQL queries to read the metadata of dashboards.
- We cached the dashboard file in-memory by preventing the download of the dashboard file from the server on each dashboard load. The dashboard file will be downloaded only once for a tenant until it is modified.
- We’ve prevented calls to designer-specific APIs in view mode.
- We optimized widget redraw events.
- We sliced the single CSS files into multiple files. So, files are downloaded in parallel to reduce the download time.
Here is a table showcasing the loading time and resource size during initial load of a dashboard before and after the latest release (v2.8).
|Static resource size (JS/CSS)||Initial loading time|
|Before v2.8||4.7 MB||5 seconds|
|After v2.8||2.9 MB||1.9 seconds|
Note: This time may vary based on the data-fetch process that depends on the data server.
If you have any questions, please post them in the comments section below. You can also contact us by submitting your questions through the Bold BI website. If you already have an account, you can log in to submit your support question. Try our Bold BI dashboards by requesting live 30-minute free demo with our experts.