How to increase Dashboard Performance in Tableau

7 min readFeb 4, 2023

There is a great whitepaper by Ben Bausili and Mat Hughes“Designing Efficient Production Dashboards” about best practices for creating dashboards. It’s interesting to look at everything, but I pulled up about a list of things to pay attention to make your dashboard work better.

It’s not a substitute for performance recording, but I’ve always wanted to structure it somehow for myself (what to do and what not to do).

There’s an excellent tool by Vitaly Kovalev to measure the performance of your workbook. It will show you as closely as possible how much time it takes to see your workbook if you are a regular user.

Data

The speed of the dashboard depends among other things on the speed of the database. Here you need to contact the database engineers and ask them to perform a detailed performance analysis and improve it (e.g. through indexes).
If you connect to the database, use special drivers for it. Drivers like ODBC, JDBC increase load time.
Extracts often work better than live connections. Live will depend a lot on the database again. Also it is a good practice to pre-aggregate your data.
When you use extracts, filter data you don’t use (user extract filters for that and the Hide All Unused Fields option). It’s better to hide fields only after all your visualizations were crated
Initial SQL is faster than Custom SQL, especially on live (but it’s harder to maintain and will be updated only with a new user session).
RLS (row level security) can also slow down the book if it’s not done properly. You can fine Best Practices here.
The built-in extracts in the workbook are faster than published datasources with an extract.
Do complex calculations at the database level and materialize them directly into the source if possible. You can create many different calculations in Tableau, but it will affect the speed too (especially LOD)
Blending slows down the workbook because it queries data from both data sources at the linking field level before merging the results into Tableau. The more unique values, the longer it takes. Blending is better to do only by large fields (for example, by category, not by id-s), or better not to do at all.

Calculations

Materialize calculations you made in Tableau by writing them directly into the extract. There’s a button there called Extract -> Compute Calculations Now. Then they will be written directly to the extract file, and not recalculated every time you access the Dashboard. Calculations that use parameters are not materialized.
When you use live connection, then try to materialize all calculations in the datasource, also because not all of Tableau’s functions will work.
LODs are often slower than Table Calculations, but TC only work well on very well constructed visualizations. It’s best not to use one or the other unnecessarily (if you can solve the problem with regular calculations) and to actually materialize as well.
Reduce the granularity of calculations. The more you aggregate at a time, the better, but if you have an LOD with a bunch of categories, it won’t be fast.
MIN and MAX are faster than ATTR and AVG. If you need to display a column with repeating values and the result is the same for all 4 functions, take MIN or MAX.
Create groups with CASE statements. The internal group creation tool is slower. For group creation use (sorted from the best options)
1. CASE
2. Tableau Sets
3. Built-in grouping function (right-click on the pill, Create > Group)
4. IF statements.
Use IN instead of OR. Since Tableau 2020.3 there is an IN operator, it works faster than OR.
The built-in Alias functionality is faster than creating names through calculations.
Reduce the number of nested calculations (when one calculation refers to another). They complicates Tableau’s work, especially when there are many IFs. The solution is materialization again.
COUNTD works slower (as you have to search for unique values). Try COUNT if possible.
Calculations with text data types and dates are also slow and it is better to materialize them. For text calculations, CONTAINS() works faster than FIND() and if you don’t need categories allocation, don’t add IF to them, just leave a logical boolean field. With dates it’s better to use DATEPARSE and MAKEDATE. Use TODAY() instead of NOW() if you need only a date without time.
The text values (string) that you give as a results of calculations or into parameters are no worse than numeric (integer) or logical (boolean) values. It makes no sense to make a special parameter with integer if you’re more comfortable with string no (the performance is the same, sometimes even the text ones are slightly faster).

from Designing Efficient Production Dashboards

Filters

Reduce the number of filters with type Show only relevant values.
Add an Apply button (it won’t filter faster, but it will be easier for the user).
Avoid filters with many inclusion or exclusion options. Take a higher level measurement, e.g. country instead of city.
Avoid filtering by aggregation results.
Filters with dates are better done by continuous date (green pills, relative or range of dates). Range is faster.
Range filters are better than detailed filters. Selecting a range of values (e.g., sales over 500 or price between $10 and $20) is a much easier query than a list of values.
You can filter through parameters too, especially between sources and sometimes it’s faster.
Filters made via LOD are better changed to Sets.
Context filters don’t speed up books (they did in older versions, but not anymore). Adding filter into context will not speed up the book.
Zoom does not filter, for example, it is sometimes more useful to add a filter by region to a map instead of having the user zoom it in.
The fastest filter types:
1. Custom Value List
2. Wildcard Match
3. Relative Date Filters
4. Browse Period Date Filters
The slowest filter types:
1. Multiple Value List
2. Single Value List
3. Compact List
4. Slider
When creating a filter action don’t pass all fields, but select specific fields to pass between sheets for filtering.
Filter action “Exclude all values” option can help too, if you don’t really need vis before action.

Sheets

Visualizations are better than text tables. Tableau is still for dataviz and huge text tables can slow your workbook down.
Reduce the number of marks used (the more different data and categories you have, the more it takes to render it). For example, in a table every cell is a mark. You can see the number of marks used at the bottom. Density marks work faster that usual ones.

Use formatting options instead of creating new calculations. For example for making KPI triangles.

Reduce the size of images (for custom shapes and images). It’s better to keep them to 50kb and 32x32 pixels.
Use PNGs rather than JPGs. They take up less space.
Polygons are slow to render and if you can do without, don’t.
Pages don’t work as filters and it’s better not to use them that way. They don’t filter data, so they’re a lot slower.
If you add a vis to the tooltip, it should loads fast, otherwise it makes no sense to add it. And just like with filters, do not pass all fields for filtering, but only necessary ones.

Dashboards

Use fixed dashboard size. It easier for Tableau to cache that.

The fewer sheets you have on the dashboard, the faster it is. It is better to have no more than 5. Complex ones can be divided into several dashboards.
Reduce the number of filters the user can interact with. Better 3–5.
Do not add anything to the dashboard what users don’t need. This is the time where you need to talk to users first.
Hide visualizations, if they are extra and users don’t use it every time. User containers’ hide button for that.
Remove unnecessary device layouts. For example the mobile version of the dashboard is created automatically. If you don’t need it — remove it.
When you create a dashboard you unnecessary containers might be created automatically — remove them too.
Do not publish all sheets to the server, use only dashboards (hide sheets is they are used in the dashboard.