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.
What drives load time
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.
Dashboard pages split work so only the active tab queries
Before you publish
- Set each chart’s Data Refresh Interval to the longest acceptable value.
- Move secondary views onto additional pages instead of one dense page.
- Prefer Last Value or pre-aggregated sources over long-range Real-Time where current state is enough. See Key data sources.
- Resolve “Not Optimized” virtual sources.
- 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
Optimize virtual sources
Fix virtual table performance in Data Sources.
Database types
Understand engine limits that force work upstream.