A slow Tableau dashboard erodes user trust and adoption faster than almost any other failure mode. Users who wait more than 10 seconds for a view to load stop using it. This guide covers the diagnostic process for identifying performance bottlenecks and the specific interventions that address each category of slowness.
A Tableau dashboard that takes 30 seconds to load is a dashboard that does not get used. Users have accurate intuitions about whether a dashboard is worth their time to open. Dashboards that are fast feel reliable. Dashboards that are slow feel untrustworthy — even if the data they eventually display is accurate.
Performance optimisation in Tableau is a diagnostic discipline. There is no single intervention that always works. The right approach depends on identifying where the time is actually being spent, then targeting the correct bottleneck.
The Performance Recorder
Every performance investigation should start with Tableau's built-in Performance Recorder. Access it via Help > Performance Recording (or Analysis > Performance Recording in older versions). Start recording, load the view, stop recording. Tableau generates a performance workbook showing a timeline of every event.
The key events in the performance timeline:
**Query execution**: time spent sending a query to the data source and receiving results. For live connections, this is database time. For extracts, this is time to scan and aggregate the extract. If query execution dominates the timeline, the bottleneck is in the data source or the extract.
**Executing layout algorithms**: time spent computing the spatial layout of marks in the view. For views with many marks or complex layout logic, this can be significant. If layout algorithms dominate, reducing mark count is the solution.
**Rendering and drawing**: time spent rendering the final visualisation. For complex views with many marks, transparency effects, or custom shapes, rendering can be a bottleneck.
**Computing functions**: time spent evaluating Tableau calculations. For complex LOD expressions or many calculated fields, this appears separately from query execution.
If query execution is the dominant time, the problem is not in Tableau — it is in the data source. No amount of Tableau optimisation will fix a slow database query. Investigate the query that Tableau is sending (visible in the performance workbook) and optimise it in the database: add indexes, pre-aggregate, materialise the join.
Extract vs Live Connection Performance
The most impactful performance decision for most dashboards is whether to use an extract or a live connection.
Live connections query the underlying database at dashboard load time. Response time depends on database performance, query complexity, concurrent load, and network latency. For fast analytical databases (Snowflake, BigQuery, Redshift) with well-designed queries, live connections are often fast enough. For slower databases (on-premise SQL Server, MySQL without appropriate indexes, unoptimised Postgres), live connections are the primary performance bottleneck.
Extracts load data from the source into Tableau's in-memory columnar format. Dashboard queries are answered from the extract, which is typically 10–50x faster than the equivalent live query for simple aggregations. The trade-off is data freshness — extract data is as current as the last refresh. For most analytical use cases, hourly or daily refresh is acceptable.
When to use extracts:
- Source database queries take more than 5 seconds
- The source database cannot handle the query load from multiple dashboard users
- Data freshness of less than 24 hours is not required for the dashboard's use case
When to keep live connections:
- Near-real-time data currency is required
- The source is a fast analytical database already optimised for the queries
- Extract size would be prohibitively large
Extract Optimisation
Even with extracts, performance can be improved by optimising the extract's content and structure.
**Materialise calculated fields**: calculated fields in Tableau are evaluated at query time by default. For calculated fields that are used frequently, storing the calculation result as a column in the extract (Materialise Calculations) shifts computation from query time to extract refresh time. The dashboard query becomes a simple column read rather than a calculation evaluation.
**Aggregate the extract**: if the finest granularity the dashboard displays is the week level, do not extract row-level data. Build an aggregated extract at the week level. The extract will be orders of magnitude smaller and query time proportionally faster.
**Filter the extract**: extract only the data required for the dashboard. If the dashboard shows only the last 2 years of data, apply an extract filter restricting to the last 2 years. Unused data in the extract wastes memory and increases scan time.
**Hide unused fields**: fields from the data source that are not used in any calculation or view increase extract size without benefit. Hide them (or exclude them from the extract) to reduce the extract footprint.
Reducing Mark Count
The number of marks in a view is one of the strongest predictors of render time. A view with 10,000 individual marks will render more slowly than a view with 100 marks, regardless of query speed.
Aggregate before displaying: a line chart showing daily data for 3 years has approximately 1,000 marks. If the analytical question is about monthly or quarterly trends, aggregate to that level. Fewer marks display faster and are often more legible.
Limit mark count for scatter plots: scatter plots with more than a few thousand marks are both slow to render and analytically difficult to read (overplotting obscures the patterns of interest). Use aggregation, sampling, or hex binning for large scatter plots.
Level of detail filter: for geographic maps with thousands of points, consider whether the analytical value of individual points justifies the render cost. Aggregate to postal code or regional level if individual point precision is not required.
Dashboard Design for Performance
The layout and content of a dashboard affect performance independently of any individual chart's query speed.
**Too many sheets on one dashboard**: every sheet on a dashboard loads independently, each sending its own query to the data source. A dashboard with 12 charts sends 12 queries simultaneously. Reduce the number of charts on a single dashboard view, moving less critical views to a secondary or detail dashboard accessible via action.
**Floating objects**: floating objects (as opposed to tiled layout) can cause layout computation overhead for complex dashboards. Use tiled layout where possible; reserve floating for specific cases where layout precision requires it.
**Images and custom shapes**: large images embedded in dashboards increase download size and render time. Use appropriately sized and compressed images; do not embed multi-megabyte images in dashboards viewed primarily on monitors.
**Device layout copies**: Tableau creates separate layout copies for desktop, tablet, and phone views. Each layout is rendered independently. If tablet and phone views are not used, remove them from the workbook to reduce the layout computation Tableau performs.
Data Source Query Optimisation
If the performance recorder shows that query execution is the bottleneck, investigate the actual query Tableau is generating. Tableau provides query inspection tools and logs the queries it sends.
Common query issues:
**Missing indexes**: for live database connections, indexes on the columns Tableau filters and joins on dramatically reduce query time. A date filter that requires a full table scan on a 100 million row table takes seconds; the same filter on an indexed column takes milliseconds.
**Expensive LOD expressions**: FIXED LOD expressions generate SQL with GROUP BY at the LOD level, joined back to the main query. For high-cardinality dimensions, this join is expensive. Consider materialising the LOD computation in a view or pre-aggregated table in the database rather than computing it on every query.
**Unoptimised joins in the data model**: joins in the Tableau data model (the relationships and joins between tables in a data source) are translated to SQL joins at query time. Unnecessary joins or joins on non-indexed columns add query latency. Eliminate joins to tables whose fields are not used in the current dashboard.
**Context filters**: context filters cause Tableau to send an additional query to materialise the context before running the main query. Use context filters only when required for FIXED LOD correctness, not as a general-purpose filter optimisation.
Our managed BI services and Tableau consulting practice diagnoses and resolves Tableau performance issues — contact us to discuss performance tuning for your Tableau environment.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →