Boosting Tableau Dashboard’s Performance
Dashboard performance should be paramount for corporates especially when processing millions of records, which can only be expected to increase with time. Fortunately, we have a solid starting point with Tableau’s online documentation. However, there are quite a few things you have to figure out on your own.
In Tableau on- and off-line watering holes you must have heard other Tableau developers say that if you get the KPI calculations from the backend (database), it’s more than enough to decrease the loading time for the dashboard. It’s a very valid point but not the only step that will boost the performance.
Tableau appreciates if your dataset is long rather than wide. So, if your dataset is already wide then the following points can help to enhance the dashboard performance.
1. First and foremost, and known to most, use extracts rather than live connections. And if need be placed as many extract filters to bring in only the essential data to the dashboard.
2. Here’s another that may be known to many. Use CASE statements wherever and whenever possible. If it becomes imperative we use IF..Then, but stick to CASE wherever you can.
3. Use MIN, MAX functions rather than ATTR functions. This is what Tableau suggests and it works wonders.
4. When it comes to a business dashboard which involves records in millions, a better practice would be to avoid showing or hiding another sheet or filter by populating or depopulating a sheet within a container. This will unnecessarily complicate the process and not to miss the additional calculation fields and/or filters that will be loaded just to make this happen. Keep it simple.
5. Filters:
a. Try using the natural filters that Tableau allows. I have observed when parameters are used to filter, it slows down the rendering time. So, until or unless it can’t be avoided, find ways to bring filters on the fields in the database. After all, parameter filters require calculations which slows the dashboard. In the reports section, using parameter filters makes the download or changes in the report, a frustrating experience. Reason with clients, if need be, and/or make them aware of the implications of using too many parameter filters.
b. Try to bring the filters from the sheets already on the dashboard, until or unless your filters have a condition and can disrupt the desired graph output. Having too many unnecessary hidden sheets on the dashboard just for the filters slows down the performance. And in case it becomes imperative to have one or two hidden sheets for filters, please ensure that you reduce the number of Marks on that hidden sheet to the minimum.
c. While specifying the filters on the sheet, whether they are context filters or otherwise, dimension or measure, please ensure that the same condition is not specified on each and every filter or field on that sheet. For example, you want products with revenue >= 0 so either you can either drag revenue to the filter pane and specify at least 0 as condition or place this condition on Product dimension filter.
6. Avoid 1 into 4 — There have been instances where what could be done in one graph was split into 4 graphs; the title from one, legend from another and what could be managed with dual axis was split into 2 graphs on 2 different sheets. What we do not realise by doing this is we are increasing the marks on the dashboard and hence affecting the dashboard performance. Use text dashboard objects for the labels or legends if it can’t be handled the natural way.
7. Use sets/parameters for handling features like Top X/Bottom X/All records. In fact, sets are as fast as CASE Statements. Creating 3 sheets for this functionality and calling for a sheet swap feature is not a viable option. Reason being, the number of marks on the dashboard is going up and you are loading the same data three times.
8. Define shading and border values to demarcate the dimensions/ measures on the graphs instead of calling another sheet for highlighting the same.
9. Lay the containers on the dashboard in a most simplistic way. Do not place a container within a container unless warranted. After laying out everything on the dashboard, see how you can get rid of extra containers. I have personally seen a difference of a second by just adjusting and removing unwanted nested containers.
10. Number of graphs on dashboard — Suggest ways of bringing down the number of graphs on the dashboard when you have millions of records to deal with. If the client is not open to the idea then utilize features like show/hide feature. They are helpful too as they utilize lazy loading which means that whatever is in the container whether sheet or object will not be rendered till it is visible.
11. In the end, hide the fields from the backend that are not needed and delete the calculated fields that are not used.
As point 1 was already there, so after implementing points 2–9 the loading time of the dashboard I was working on, was reduced by 26.08 percent and 43.48 percent just by implementing point 10. Bringing in the calculated fields from the backend and point 11 has yet to be implemented. The percentages are not mentioned to brag but to corroborate the fact that these points are also very effective.
With this I’m done with my list. However, it is not a complete list as it is restricted to what I did in one particular project and so I will recommend that you familiarize yourself with the Setting & Performance feature of Tableau and go through Tableau’s online document to get more knowledge on how to improve the performance conducive to your scenario. Au revoir!!
