A slow report can be caused by a large model, an expensive measure, a slow source query, too many visuals, or capacity pressure. Optimizing without measuring risks adding complexity without improving the experience. Use this sequence to find the bottleneck.
Describe the symptom precisely
Is the delay during data refresh, opening the report, changing a slicer, or exporting? Record which page, visual, filter selection, and approximate wait time. Compare a cold first load with a repeated interaction. Different symptoms point to different layers.
Measure report and visual cost
Use Power BI's Performance Analyzer to record visual load times for the slow page. Copy a visual's query for inspection when appropriate. If one chart dominates, test it with fewer fields and a simpler measure. If every visual is slow, inspect model size, source response, and service capacity rather than optimizing one chart at a time.
Reduce the number of visuals competing on one page. Each visual may issue work when filters change. Remove unused visuals, redundant cards, excessive high-cardinality detail, and slicers that do not serve a real task. Use drill-through or separate pages when readers need details occasionally rather than all at once.
Improve the model before micro-tuning DAX
- Remove unused columns and rows from the model, preferably at source or in the query where appropriate.
- Use a star schema and avoid unnecessary many-to-many or bidirectional relationships.
- Review high-cardinality text columns and duplicate descriptive attributes that bloat storage.
- Check data types and avoid storing timestamps when only a date is needed.
- For large facts, evaluate aggregation or incremental refresh only when the source and business requirements support them.
Inspect measures and queries
Use a simple base measure as a baseline, then add one calculation at a time. Complex iterators over huge intermediate tables, repeated evaluations, and broad filter removal can be costly. Avoid assuming that a shorter formula is faster; profile the actual query and result in a representative model.
For DirectQuery or composite models, examine source query plans and network round trips with the database owner. Query folding and source indexes can matter more than visual formatting. In Import models, refresh cost and model memory may be the limiting factors instead.
Use a controlled test
- Save a copy of the report or record a baseline.
- Change one thing, keeping the same filters and environment.
- Repeat the same interaction several times and compare timings; network and cache conditions vary.
- Check that totals and interactions remain correct.
- Keep the change only if the improvement is repeatable and the maintenance cost is reasonable.
Check service conditions
A report that is fast in Desktop can behave differently in the service because of gateway latency, concurrent users, capacity, permissions, or source connectivity. Test with realistic data volume and the intended audience. Share refresh duration and report-interaction timings with the workspace or capacity administrator when needed.
Performance work is a tradeoff. The goal is not the smallest possible model at any cost; it is a responsive, correct report whose design can still be maintained by the team.
