Keeping Dashboards Fast
A dashboard runs every query on it. Slow dashboards get abandoned, so this deserves attention before people stop opening them.
Where to find it
Architect Panel → Dashboards:
- BI Dashboards — the dashboard and its blocks
Architect Panel → Data:
- Query Builder — where the underlying queries are tuned
Caching, and what it costs you
Results are cached, so a dashboard several people open in a morning runs its queries once rather than once each. The first load after the underlying data changes is the slow one; subsequent loads are not.
The trade is freshness. Decide how current each figure genuinely needs to be — an operational queue count wants to be live; a monthly revenue trend does not, and pretending it does costs you performance for no benefit.
Common causes of slowness
- Too wide a period. Most dashboard questions are about now. Three years of history to show this week's figure is wasted work on every load.
- Too many blocks. Every block is a query. Ten is a dashboard; thirty is a report that happens to have charts.
- High-cardinality groupings. Grouping by something with thousands of distinct values produces a result nobody can read and takes time to produce. Use top-N.
- Missing indexes. Dates and the columns you filter on should be indexed. This is the single highest-value fix and the one most often overlooked.
- Unbounded listings. A list-mode block with no row cap will happily try to render everything.
Where the data is genuinely large
Aggregating a long movement or journal history is expensive however well it is written. Where a figure is needed often and changes rarely, schedule it and deliver the result rather than computing it live every time somebody looks.
Test at the size it will be
A dashboard built against six months of data behaves differently against six years. If you are early in a system's life, run the query against realistic volumes — or against a copy with generated data — before promising it to anyone.
Worked example
A finance dashboard took eleven seconds to load. Two changes fixed it: the revenue trend was narrowed from five years to eighteen months, and an index was added on the journal date column. It now loads in under a second, and nobody has asked for the missing three years.
Recommendations
- Index dates and filter columns first. Usually the biggest single win.
- Narrow periods aggressively. Add history back only if somebody asks.
- Cap every listing.
- Move genuinely heavy work to a schedule.