Why does a Tableau dashboard with many worksheets and filter actions respond slowly to clicks?

## Where the time goes When a Tableau dashboard is slow, the time is in one of a few places, and they need different fixes: - **Query execution** — the data source answering the worksheet's queries. - **Query volume** — many separate queries, each cheap, adding up in round trips. - **Mark rendering** — hundreds of thousands of marks in a view the browser must draw. - **Calculation** — expensive calculated fields or table calculations computed after the data returns. - **Layout** — a very large number of objects and containers. Actions bear on the first two directly. ## The per-worksheet query model Each worksheet on a dashboard generates its own queries against its data source. There is no single dashboard-level query. Filter cards add to this: a card set to show **only relevant values** must itself query for the list of values that survive the other filters, and it re-queries whenever those filters change. So the baseline cost of opening a dashboard is roughly the sum of its sheets and its dependent filter cards. ## What a filter action multiplies A filter action applies a new filter to each target sheet, which means each target re-queries. Target eight sheets and one click costs eight sets of queries. This is the mechanism behind the most common performance complaint on a busy dashboard, and it is usually created accidentally: the **Use as Filter** funnel icon generates an action whose target list is *every other sheet on the dashboard*. Add that to two or three sheets and every click re-queries the whole dashboard several times over. Trigger choice multiplies it again. **Run on Hover** fires as the pointer crosses marks, so idle mouse movement produces a stream of query rounds and the dashboard feels like it is thrashing. Hover is acceptable for a highlight action, which repaints already-rendered marks and issues no queries; it is nearly always wrong for a filter action. ## What to change, roughly in order of payoff **Narrow the target lists.** Open Dashboard > Actions and, for each filter action, uncheck the sheets that do not need to change. Most dashboards need one or two targets per interaction, not all of them. **Prefer highlight where the reader needs context anyway.** A highlight action costs nothing at the data source, and for peer-comparison charts it is the better design as well as the cheaper one. **Move expensive drill-through to Run on Menu.** Nothing fires until the reader clicks a tooltip link, which turns an accidental cost into a deliberate one. **Reduce the sheet count.** Eight small charts often want to be one chart with a small-multiples layout, or a single sheet using a parameter to swap the measure. Fewer sheets means fewer queries in every phase. **Reduce mark count.** A view drawing very large numbers of marks is slow to render regardless of query time. Aggregate to the grain the reader actually reads, and put the row-level detail behind a filter action into a detail sheet that starts empty. **Reduce the work per query.** This is where the data source, not the dashboard, is in charge — the connection type, the aggregation, and how much the source is asked to compute. That trade-off belongs to how the workbook connects to its data rather than to the actions themselves. **Simplify calculations that run per mark.** Nested table calculations and row-level string operations over many rows are computed after the data returns and can dominate the click-to-paint time even when queries are fast. ## Measure, do not guess Tableau Desktop ships a **Performance Recorder** (under Help > Settings and Performance) that records a session and produces a workbook breaking the time down by event: executing query, computing totals, geocoding, rendering, and so on, with the query text for the slow ones. Run it, reproduce the slow click, and read what actually dominated. On Tableau Server or Tableau Cloud the equivalent evidence comes from the site's administrative views and logs, which show how long views take to render for real users under real concurrency. The reason to measure first is that the fixes point in opposite directions. If query execution dominates, changing the trigger from hover to select barely helps and the answer is in the data source. If query *volume* or rendering dominates, tuning the source will not help and the answer is fewer sheets and narrower actions. ## Concurrency is a separate problem A dashboard that is acceptable for one author on their laptop can be unacceptable when fifty people open it at once, because every session repeats the same query rounds against the same source. That is a capacity conversation about the published environment and the data source's ability to serve concurrent analytical queries, and it is why an expensive per-click design is worth fixing even when the author's own experience feels fine.