Keeping Dashboards Fast

A dashboard runs every question on it. Slow dashboards get abandoned, so this is worth attention.

Where to find it

Architect Panel → Dashboards:

• BI Dashboards — the dashboard and its blocks

Caching

Results are cached, so a dashboard several people open in a morning runs its queries once rather than once each. The first load after 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.

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.
• Too many blocks — every block is a query. Ten is a dashboard; thirty is a report.
• High-cardinality groupings — grouping by something with thousands of distinct values produces a result nobody can read and takes time to produce.
• Missing indexes — dates and the columns you filter on should be indexed.

Where the data is large

Aggregating a long movement or journal history is genuinely expensive. Where a figure is needed often and changes rarely, consider a scheduled report delivered by email rather than a live block somebody waits for.

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, check the query against realistic volumes before promising it to anyone.