# 33.3× Faster Dashboards > How one Sigma dashboard went from ten widget-level query paths to a shared data model — and how to make the same kind of change without changing what the numbers mean. - Author: Paul Yu - Role: Senior Analytics Engineer - Employer: Viral Nation - Year: 2026 - Theme: Speed - Human article: [https://paul-yu.com/case-studies/dashboard-performance-engineering](https://paul-yu.com/case-studies/dashboard-performance-engineering) - Structured data: [https://paul-yu.com/agent/case-studies/dashboard-performance-engineering.json](https://paul-yu.com/agent/case-studies/dashboard-performance-engineering.json) ## Evidence | Value | Measure | Evidence level | | --- | --- | --- | | 2.76s | faster matched page load | Measured | | 10 → 1 | query paths unified | Repository backed | | 23.4% → 5.6% | reported failed-query rate | Measured | | 333 / 336 | identity records matched separately | Measured | ## Situation About ten parallel query paths rebuilt joins, relationships, and metrics inside separate dashboard widgets. The page was slow, and those private paths could also return different answers to the same question. ## Task Give every widget one trusted data source and reduce the work performed after a user opened the page. ## Action I moved shared identity rules, relationships, latest-row logic, and metrics into prepared warehouse models. Dashboard widgets then filtered and displayed the same governed result. ## Result One matched saved view loaded 2.76 seconds faster at the median across three runs. The production comparison showed 33.3× faster median queries and a 76% lower reported failed-query rate. All 232 V2 failed-status rows were Sigma cancellations, leaving zero non-cancellation failures during launch. ## System flow Matched test cases → Old + new query paths → Latency distribution → Release decision ## Technical notes ### Pre-aggregation The warehouse computes reused logic ahead of time. A dashboard query can read a smaller prepared table rather than rebuild the full answer. ### P90 latency P90 is the time that 90% of queries beat. It shows the slow end of the experience, which an average can hide. ### Regression benchmark The old and new systems answer the same test cases. This catches a fast query that changed the meaning of the result. ## Ownership I built major parts of the new data and dashboard path. I also designed the comparison, ran it, and documented the remaining mismatches. ## Limitations The matched test covered one saved view with three runs per workbook. Source paths, query shapes, and cache use differed, so it supports the redesigned experience but does not isolate one cause. Consistency is a secondary effect of the shared model, not a separate controlled experiment. ## Takeaway The main win was speed. A secondary win was consistency: one shared model replaced private widget paths that could disagree on the same business fact. ## Tools Snowflake, Sigma, SQL, Dynamic tables, Latency benchmarking