Tableau Performance (load time / query time)

Tableau Performance Optimization 

1. Identifying the Largest Contributor to Load Time

With your server on another continent, you have three main bottleneck candidates: 

How to IdentifyNetwork latency/bandwidth

| Use ping and traceroute to your Tableau Server. Check round-trip time. Use browser DevTools (Network tab) to see TTFB (Time to First Byte) vs. content download time. If TTFB is high but query time in Performance Recording is low, the network is the bottleneck. 

("Background Tasks", "Stats for Load Times"). 

Additional tools beyond Workbook Optimizer and Performance Recording: 

• Tableau Server Log files (tabadminagent logs, vizqlserver logs) — parse with tools like LogShark or TabMon (now deprecated but still useful for older setups).
• TabJolt — Tableau's load-testing tool. Simulates concurrent users to stress-test your server.
• Tableau Server Admin Views — built-in dashboards under Server Status showing load times per view, sessions, backgrounder tasks, etc.

2. How Valuable Is It to Remove/Hide Unused Fields?

High value for extracts. Here's why: 

• When you create a .hyper extract, every field is stored as a column. Unused fields still consume disk space, memory, and increase extract refresh time.
• With 100M rows, each unnecessary column could add hundreds of MB to the extract file size.
• Hiding fields does NOT help — hidden fields are still in the extract. You must use "Hide All Unused Fields" and then explicitly remove them from the extract, or better yet, write a Custom SQL / adjust the extract to only include needed columns.
• Recommendation: Audit your fields. On a 100M-row extract, removing even 10 unused columns can dramatically reduce extract size and query time.

Impact: HIGH

— potentially 20-50% improvement in extract size and refresh time. 

3. How Valuable Is "Show Relevant Values Only" in Filters?

Very costly — avoid it when possible. 

• "Only Relevant Values" forces Tableau to run an additional query per filter to determine which values are valid given the current context of other filters.
• With 100M rows and multiple filters, this creates a cascade of dependent queries — each filter change can trigger re-queries on all other "relevant values" filters.
• Recommendation: Switch to "All Values in Database" or "All Values in Context" where possible. If users need guided filtering, consider using parameter-based filters or dashboard actions instead.

Impact: HIGH

— can reduce dashboard load time by 30-60% in filter-heavy dashboards. 

4. How Valuable Is Reducing the Number of Filters?

Significant value.

Each Quick Filter on a dashboard generates at least one query (to populate the filter list) plus the main data query. More filters = more queries = longer load. 

Recommendations: 

• Replace multiple quick filters with a single parameter + calculated field approach where possible.
• Use filter actions (clicking on a chart to filter) instead of dropdown filters — they don't require a population query.
• Apply filters at the data source level rather than the worksheet level to reduce query scope.
• Use context filters strategically to narrow the dataset before other filters execute (but use sparingly — each context filter creates a temp table).

Impact: MEDIUM-HIGH

— depends on how many filters you currently have. 

5. Overcoming LOD (Level of Detail) Expressions

LODs are powerful but expensive because they generate

that the engine must compute independently and then join back. 

Strategies to reduce or replace LOD usage: 

Instead of LOD...Try this...{FIXED [Dim] : SUM([Measure])} | Pre-aggregate in the database

— create a summary table or materialized view at the needed grain and blend/join it in. 

LOD for "percent of total" | Use

(SUM([Sales]) / TOTAL(SUM([Sales]))) — these compute in Tableau's cache, not via query. 

LOD for cohort assignment | Compute the cohort

and store it as a column in your data. 

LOD for "first/last" values | Use

in your database (e.g., ROW_NUMBER(), FIRST_VALUE()) and materialize the result. 

Multiple nested LODs | This is a strong signal that the

General rule: If an LOD expression is used on every dashboard, it should become a physical column

in your data source via ETL. 

Impact: HIGH

— LODs on 100M rows are among the most expensive operations. 

The single highest-impact change for your scenario (100M rows, extensive dashboards, cross-continent server) is almost certainly

to only the fields and rows actually needed. The filter tuning ("relevant values", filter count) is the next tier — easy wins with significant payoff.