Why dashboards get slow and how to fix them

Start with a stopwatch and a browser network panel. A dashboard that takes twelve seconds may spend nine in the database, one transferring, and two drawing. Optimising the visual layer in that case changes almost nothing.

Test one visual at a time with filters cleared, then with the heaviest filter combination. Check the query log or the tool's performance analyser for duration and rows returned. If the query is fast but the page is slow, the problem is page weight or the number of concurrent queries.

Every visual should receive the smallest table that can answer its question. Aggregate in SQL or the semantic layer, select only the columns used, and filter to the required history window. A chart showing monthly totals does not need transaction rows.

Summary tables and materialised views move work from query time to refresh time. The trade-off is freshness and flexibility: a daily summary cannot answer a question about the last hour, and a fixed summary cannot support an unplanned breakdown. Keep a detail path for drill-through when the summary is not enough.

A star schema with clean relationships usually outperforms a wide table with many-to-many joins. Use correct data types, avoid calculated columns over large fact tables, and push row-level calculations into the source where possible.

Partition large tables by date and keep statistics current. Indexes and materialised views help, but only for the filters people actually use. A model tuned for one report can slow another, so test the top queries together rather than in isolation. Bidirectional relationships and many-to-many bridges are common hidden costs.

Many BI tools issue a query per visual. A landing page with twenty cards can send twenty queries at once, and the database may serialise them. Reducing the visual count or combining cards into one table often produces a larger gain than rewriting a single query.

Choose a landing page budget and treat it as a design constraint. Eight to ten visuals is a workable rule of thumb for a summary page, with detail behind drill-through. Avoid slicers that force a full refresh on every click, and do not preload hidden tabs that nobody opens.

Large images, embedded documents, custom web fonts, and images used as backgrounds all add transfer time. Compress images, limit font families, and remove decorative elements that do not carry information. A dashboard is a tool, not a poster.

Tables with thousands of rows and conditional formatting on every cell are expensive to render. Paginate or aggregate the table, apply formatting to the visible range, and avoid nested containers that force repeated layout work. Test on a mid-range laptop and a phone, not only on the developer machine.

Work from the largest cost down, changing one layer at a time. Keep a baseline measurement so you can tell whether a change helped or merely moved the delay somewhere else. A dashboard that loads quickly but shows the wrong grain is not a performance win.

Performance work is iterative and slightly unglamorous. The table below maps common symptoms to the layer worth inspecting first, but confirm with a measurement before committing to a fix.