> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.kodelabs.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Dashboard performance
> Improve Building BI dashboard load time by reducing query frequency, source cost, and rendering load.
A slow dashboard is almost always doing too much querying. Performance comes from sending fewer, cheaper queries.
Refresh less often than feels natural, split heavy dashboards across tabs, prefer pre-processed data sources, and keep virtual tables optimized. Optimization is a design discipline, not a setting you flip at the end.
Every widget on a dashboard issues queries to a database. Load time is the sum of that querying. Smart decisions while building can save you time in the long run of development.
## What drives load time
| Factor | What drives cost | Lever |
| --------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- |
| Refresh frequency | Each chart re-queries on its Data Refresh Interval | Choose the longest interval you can tolerate |
| Query volume per page | Many charts mean many simultaneous queries | Split work across **tabs** so only the active page queries |
| Source weight | Raw history over long ranges is expensive | Prefer Last Value or reduced-frequency sources |
| Virtual table health | A view runs every time you use it | Keep virtual tables optimized |
| Calculated fields | Calculated columns and metrics cannot use window functions or aggregations of aggregations | Put that logic in a virtual table instead |
| Clutter | Extra widgets cost reads and attention | Fewer, well-chosen widgets — see [Styling best practices](/products/building-bi/widget-customization#styling-best-practices) |
Practical defaults:
* Live operational data may warrant a short refresh. Historical trends are often fine hourly or daily.
* Shared links and scheduled reports have their own refresh rates — keep them as infrequent as the data allows (often one hour).
* Building BI surfaces a "Not Optimized" status on virtual sources and can suggest fixes. See [Physical vs virtual data sources](/products/building-bi/concepts/physical-vs-virtual-data-sources).
Splitting a dashboard across pages is one of the highest-leverage levers. Only the active page queries.
## Before you publish
1. Set each chart's Data Refresh Interval to the longest acceptable value.
2. Move secondary views onto additional pages instead of one dense page.
3. Prefer Last Value or pre-aggregated sources over long-range Real-Time where current state is enough. See [Key data sources](/products/building-bi/data-sources#key-data-sources).
4. Resolve "Not Optimized" virtual sources.
5. Remove decorative or unused widgets before publish.
## Speed costs freshness and detail
Longer refresh intervals mean slightly staler data. Tabs mean a click to reach the second view. Pre-aggregated sources mean less granular drill-down. Match those trades to how fresh and detailed the data must be for that audience.
* Operational alerting can genuinely need frequent refresh. Do not blanket-apply long intervals.
* Optimizing a shared virtual source affects every dashboard using it. Validate before saving — changes are global.
* Some slowness originates upstream (integration latency, site data volume). Dashboard tuning cannot fix that.
## Next steps
Fix virtual table performance in Data Sources.
Understand engine limits that force work upstream.