workbook-performance-audit

name: workbook-performance-audit description: A repeatable, evidence-first Tableau workbook performance audit — run the Performance Recorder, read the longest events, and apply the right lever per dominant event category (Executing Query / Computing / Rendering / Connecting). Use when a workbook or dashboard is slow and you need the cause, not a guess.

Workbook Performance Audit

Owner: tableau-data-architect (primary) + tableau-viz-engineer (rendering/marks side). Grounded in: ../../knowledge/data-performance-decision-trees.md Diagnosing a slow workbook (the Performance Recorder ladder) tree.

A disciplined procedure so a "slow dashboard" ticket is diagnosed from measured evidence, not from whichever lever the author reached for first. The #1 failure (see the scenario bank, 2026-06-05-slow-dashboard-quick-filter-domain-queries.md) is spending a day "optimizing calcs" when the cost was in many domain queries — because nobody ran the recorder first.

When to use

Any time a workbook is slow to load, slow on a filter/parameter change, or slow to render — and before changing a single calc, filter, or extract. Also as a pre-publish gate for any dashboard headed to a governed prod site.

The procedure (evidence first)

Reproduce + record. Turn on the Performance Recorder (Help → Settings and Performance → Start Performance Recording in Desktop; or the recording workflow on Server/Cloud [verify-at-build]). Reproduce the exact slow action (load, this filter, that parameter). Stop the recording to generate the performance workbook.
Sort events by duration — read the longest first. Do not start fixing the first thing you notice. Identify the dominant event category by total time:
- Executing Query — database/engine returning rows. Sub-split: few slow queries vs many queries.
- Computing / Generating — an expensive calc / LOD / table calc computing per query.
- Rendering — VizQL drawing marks (client/server).
- Connecting / Geocoding — connection or geocoding overhead.
Apply the lever for the dominant category (traverse the decision-tree leaf):
- Executing Query — few slow → filter at source, fix the relationship/join, aggregate the extract, index upstream. (../../best-practices/perf-filter-at-the-source.md)
- Executing Query — many → restore query fusion (same source / grain / filters) and kill high-cardinality "show all values" quick-filter domain queries → "Only Relevant Values" / wildcard. (../../best-practices/perf-context-filters-and-query-fusion.md)
- Computing / Generating → push the calc into Prep or materialize it in the extract; fix LOD addressing/partitioning. (../../best-practices/prep-incremental-and-idempotent-flows.md)
- Rendering → reduce mark count (aggregate, cap detail, split a giant crosstab into summary + drill). (../../best-practices/perf-minimize-marks-and-quick-filters.md)
- Connecting / Geocoding → prefer an extract; cache geocoding / use a spatial join. (../../best-practices/data-extract-vs-live-by-freshness.md)
Change ONE thing, re-record, compare. Performance work is iterative; re-run the recorder after each change so the improvement is measured, not assumed. Stop when the dominant category is under the SLA.
Check the structural defaults (cheap wins, even before the recorder confirms):
- Extract vs live carries a stated freshness reason; filters pushed to the lowest layer; no high-cardinality "all values" quick filters; mark count is bounded; LOD/table-calc addressing is explicit; dashboard sheets share source/grain so the engine can fuse.

Anti-patterns this audit catches

Optimizing calculations when the cost is in Executing Query (the recorder shows it).
High-cardinality "show all values in database" quick filters firing per-load domain queries.
A 100k+-mark crosstab rendered on a summary dashboard.
Sheets diverging on grain/filters so query fusion never engages.
A live connection with no stated freshness need paying per-interaction latency.

Output

A short audit report:

Slow action: <the exact reproduced action>
Recorder evidence: <dominant event category + total ms + the longest events>
Diagnosis: <decision-tree leaf reached + why>
Levers applied: <one per change, with before/after recorder numbers>
Result: <new load/interaction time vs the SLA>
Residual / escalations: <upstream source/index work → data-platform; security filters → security-reviewer>

Follow the team Output Contract + the cross-plugin Structured Output Protocol. Don't report "I optimized it" — report the measured before/after and the category that drove the win.