Analyticsadvanced
Dashboard Design & Performance Optimization
Explain how dashboard structure, page layout, and query design choices affect load performance and user experience at scale.
A dashboard that looks great in a demo with five test users can crawl in production with five hundred concurrent users if it wasn't designed with performance in mind — interviewers ask about this to separate candidates who've only built reports from those who've operated a BI platform under real load.
It's like ordering at a restaurant: asking the kitchen to prepare fifteen separate small dishes one order ticket at a time is slower than sending one consolidated order for the same total food, and it's slower still if the kitchen starts cooking dishes nobody at the table actually wanted yet.
Key Concepts
1
The biggest lever is minimizing the number of distinct queries a dashboard page fires on load — every analysis on a page (and every view within a compound layout that isn't lazily loaded) triggers its own logical SQL request, so a page with fifteen small analyses can be far slower than one page with three well-designed, denser ones. Using dashboard prompts with a shared presentation variable (rather than fifteen independent per-analysis filters) also reduces both design complexity and the chance of inconsistent filtering across the page.
minimizing the number of distinct queries a dashboard page fires on loaddashboard prompts with a shared presentation variable
2
Other concrete techniques: enabling "Use Saved State" / navigate-on-demand patterns so secondary dashboard pages or heavy detail views only query when the user actually clicks into them, rather than pre-loading everything; leaning on aggregate navigation and caching (covered elsewhere) so the underlying queries themselves are cheap; being deliberate about default prompt values so the very first page load doesn't default to "show everything" (the single most common cause of a slow first impression); and using the Usage Tracking data to identify which specific dashboards/analyses are the slowest in production, rather than guessing.
"Use Saved State" / navigate-on-demand patternsaggregate navigation and cachingdefault prompt valuesUsage Tracking
3
A senior-level answer also mentions guided navigation (conditionally showing/hiding whole dashboard sections based on a condition, so irrelevant expensive sections never even query for users who don't need them) and the tension between "one dashboard to rule them all" versus purpose-built, narrower dashboards per audience — fewer, more targeted queries per page almost always outperforms one mega-dashboard trying to serve everyone.
guided navigationpurpose-built, narrower dashboards per audience