Dashboard Design
Part of BI system performance and cost control
Diagnosing slow dashboards before replacing the tool
Reproduce a slow dashboard action, locate the delay, and test whether a targeted fix meets the reader’s need before considering replacement.
Before replacing a slow dashboard tool, reproduce the delayed action and locate where the waiting occurs. Separate visual rendering from model calculation, source queries, refresh, and gateway or network effects. A replacement that runs the same slow source query may inherit the delay.
Make the complaint repeatable
Ask whether the problem is first page load, a filter change, a drill into detail, or a refresh that finishes too late. Record the report and page, filter state, approximate time, user role, and whether the figures were current. Measure the action where readers encounter it.
Keep the data snapshot, device, connection, and report version comparable where practical. Record whether the report or source result was already cached. If the delay appears only when colleagues are active, include a representative busy period as well as a quiet one.
Split the wait
| Observation | Next inspection | Qualification |
|---|---|---|
| One visual is slow | Its query, calculation and display time | It may also wait for other page work. |
| Every visual slows after a filter | Source and model work triggered by that interaction | Confirm which queries reach the source. |
| Page is quick but figures are old | Source load, model refresh and visible cutoff | A new render does not prove current data. |
| Delay appears at busy times | Concurrent queries, refreshes and capacity | A quiet test may miss contention. |
In Power BI, Performance Analyzer records visual load durations after interactions while editing a report, and it breaks each load time into categories, such as the time the DAX query took to run. It can help identify which visual is affecting report performance and which aspects are taking the longest duration.
Change the identified cause
If a dense page is responsible, move detail to another view. If a source query reads unnecessary data, narrow it without changing the approved population. If model calculation is slow, review the calculation and relationships with its owner. If refresh overlaps interactive use, examine the schedule before adding capacity.
Compare the old and revised headline figure, useful breakdown, cutoff, and access for representative users. Measure the same action again under comparable conditions. A shorter wait is useful only if the report still answers the approved question.
Before vs After Dashboard Optimisation
- Data Freshness
- Old figures on first render → Current data after refresh
- User Impact
- Multiple users report delays during peak hours → Smooth experience under load
Decide whether replacement is justified
Set an acceptance case for the action, audience, permitted data, expected figure, freshness, and acceptable wait under a stated workload. Consider replacement when feasible changes to the current arrangement cannot meet that need. Apply the same case to the candidate. A demonstration using a smaller extract or different filters does not establish that it will solve the reported delay.
Replacing a Dashboard Tool: Pros and Cons
- ProsNew tool may offer better performance, modern UI, and enhanced integration with Australian systems like ATO or MyGov
- ConsSame underlying slow query may persist; costs of migration, training, and compliance with AU data residency rules (e.g., via AWS Sydney region)
