Your dashboard is slow, and the dashboard is not the problemYour dashboard is slow, and the dashboard is not the problem

Someone asks why the sales dashboard takes four minutes to load. The BI tool is the thing they can see, so the BI tool is what gets blamed. A faster licence tier is discussed. Sometimes it is even bought.

It rarely helps, because the four minutes were not spent rendering charts. They were spent doing work that should have happened hours earlier, and that gets redone on every single refresh.

What a slow dashboard is usually doing

Open the query behind a slow report and you tend to find the same shapes. It joins five source tables at read time. It casts text columns to dates because nobody fixed the types upstream. It filters on a computed expression, so no index can help. It deduplicates rows, which means the source has duplicates that were never resolved. And it does all of this again for every user, every morning, at the same time.

None of that is a visualisation problem. It is a data preparation problem that has been pushed downstream until it became visible.

Move the work, don't repeat it

The layered approach people label Bronze, Silver and Gold is unglamorous and it earns its keep here. Bronze is what arrived, kept as it arrived. Silver is that data cleaned, typed and deduplicated once. Gold is the shape the question actually needs: a fact table with its dimensions, already aggregated to the grain people ask about.

The point is not the names. The point is that each expensive operation happens once, on a schedule, rather than once per viewer per refresh. A report reading a gold table is doing almost no work: filter, aggregate, draw.

If a calculation is the same for every user, it should not run once per user.

The incremental question

The second thing that makes reports slow is reprocessing history. A pipeline that rebuilds three years of orders every night in order to add yesterday's will get slower every night, forever, by construction.

Incremental loading fixes it, and it is mostly a question of being able to answer two things: what is new since last time, and what does it mean to run this twice. The first needs a watermark: a reliable updated-at column, a change feed, a sequence. The second needs the load to be idempotent, which is a large enough subject that it has its own piece.

What to actually check

• How long does the slowest query behind the report take on its own, outside the BI tool?
• Is it reading a prepared table, or joining raw sources at read time?
• Does the nightly job reprocess everything, or only what changed?
• Are types fixed once upstream, or cast in every query that touches the column?
• How many people trigger the same expensive refresh within the same ten minutes?

The answers usually point upstream. If they do, no dashboard setting will save you. The good news is that the fix is durable. Work moved into a pipeline stays moved.