Addresses a coverage gap kapa.ai surfaced: users repeatedly ask about
max chart count per dashboard, a switch to cap concurrent chart loads,
and how per-tab lazy loading works. Existing docs only mentioned
DASHBOARD_VIRTUALIZATION in passing via the feature flags page,
leaving users digging through GitHub issues and source for definitive
answers.
New page at /admin-docs/configuration/dashboard-performance covers:
- No hard chart-count cap; practical thresholds (~25/~50 friction
points) with caveats about query complexity.
- DASHBOARD_VIRTUALIZATION (default True) — row-level viewport
rendering, with the concrete behavior pulled from Row.tsx (1
viewport-height render-in margin, 4 viewport-heights unmount,
embedded mode keeps charts mounted, headless skips entirely).
- DASHBOARD_VIRTUALIZATION_DEFER_DATA (default False) — supplementary
flag that also defers the data fetch.
- Per-tab lazy loading is on by default with no flag — content in
inactive tabs doesn't render or fetch.
- No frontend concurrent-query limiter; concurrency is bounded by
browser per-origin caps (~6) and backend worker count.
- Splitting strategies in order of effort: tabs → cache → async
queries → multiple dashboards → warehouse-side pre-aggregation.
- Cross-links to Caching, Async Queries, and Feature Flags docs.
