A dashboard I own at ADEK had quietly become the kind of thing people stopped opening. Not because the data was wrong — because it took a full minute to load, and a minute is long enough that people route around a tool instead of waiting on it. By the time I was done, the same dashboard loaded in about 15 seconds. Nothing about the fix was clever. It was a checklist, applied in order, on a dashboard that had accumulated a year of "just add one more thing" requests.

Start by measuring, not guessing

Tableau's Performance Recorder is the first stop, always, before changing anything. It timelines every query, every render, every calculation against the wall clock, and it usually points at two or three specific things rather than "everything is slow." Guessing at the bottleneck and optimizing the wrong worksheet wastes a redesign cycle you don't need to spend.

For this dashboard, the recorder made the culprit obvious: a handful of table calculations were being recomputed per-mark on every filter change, on a dataset that had grown well past what the dashboard was originally designed against.

The checklist that got it from 60s to 15s

Live connection → extract. This is usually the single biggest lever. A live connection sends every interaction back to the source database as a fresh query; an extract is Tableau's own columnar store, built for exactly this access pattern. Switching this dashboard to an extract, with a scheduled refresh instead of live queries, did more for load time than everything else on this list combined.

Filter earlier, not later. Context filters and data source filters run before the rest of the query plan, so anything that can be excluded up front should be — not applied as a dashboard filter that still has to touch the full dataset first. I moved several "always-on" filters (an active-status flag, a date-range floor nobody was reporting outside of) into the data source itself.

Cut calculated fields down to what's displayed. Table calculations and row-level calculated fields that were computed but not actually shown anywhere were still costing render time. If a field isn't feeding a mark, a tooltip, or a filter, it doesn't belong in the workbook.

Reduce marks per view. A few worksheets were rendering far more marks than a person could usefully read at once — sub-category breakdowns nobody drilled into by default. Aggregating those to the level people actually looked at, and pushing detail behind an on-demand filter action instead of rendering it always, cut rendering cost directly.

Check what's actually on the dashboard, not just each sheet in isolation. A worksheet that's fast on its own can still be slow as part of a dashboard if it's tied to a dozen filter actions firing on every click. I audited every action for whether it needed to run against every sheet, or just the ones actually affected.

Why this mattered beyond the stopwatch

Load time isn't a vanity metric on an internal dashboard — it's the difference between a tool people build a habit around and one they quietly stop trusting. The same year I fixed this, a separate registration-readiness dashboard I built went from 25K to 49K in student participation partly because staff actually opened it during the registration window instead of falling back to spreadsheets. Speed is a feature, and on internal tools it's often the feature that decides whether any of the other features get used at all.