Key takeaways
- Establish a baseline with Performance Analyzer before changing anything.
- A narrow star schema with clean types and single-direction relationships removes most avoidable work.
- DAX should filter columns and scan less, not just look shorter.
- Test the published report on a typical device, because rendering and capacity load matter as much as query speed.
On this page
Measure before you tune
Performance work starts with a baseline. Use Performance Analyzer in Power BI Desktop to record each visual's duration, and separate the DAX query time from the visual display time. A slow visual may be waiting on the model, or it may be drawing too many points.
Record the baseline in a table: page, visual, duration, row count, and the measure involved. Change one thing at a time and repeat the same interaction. Without a baseline, a faster-looking report is only an impression.
Set a budget for the slowest interaction and compare against it. A page that responds in a second feels different from one that takes five, but the acceptable target depends on the task and the device.
Shrink the model
Model size is not only about disk. Fewer columns mean less compression work, smaller scans, and a field list users can understand. A narrow fact table with the right keys usually beats a wide extract with every source column.
Compression depends on cardinality, so a single high-cardinality text column can cost more than many small numeric columns. Check the column statistics before assuming a wide table is the only problem.
- Remove columns no visual, relationship, or measure uses.
- Prefer integer keys and avoid high-cardinality text in fact tables.
- Fix data types at the source or in Power Query; do not store dates as text.
- Replace calculated columns with Power Query steps where the logic allows.
- Disable Auto date/time for models that already have a proper date table.
- Check that the date table covers the reporting range but not decades of empty dates.
Fix the relationships
Use a star schema with one-to-many relationships and single-direction filters. Bidirectional relationships can produce ambiguous paths and force the engine into more work. If a business question needs a bidirectional filter, define it in a measure with CROSSFILTER rather than changing the model for every report.
Check that relationship columns have the same data type and that the dimension key is unique. A many-to-many relationship caused by duplicate keys will slow queries and produce inflated totals. Hide foreign keys so users do not group by them by accident.
Write DAX that scans less
Use DIVIDE instead of a manual divide-by-zero check. Store repeated expressions in variables so they are evaluated once. Filter columns, not entire fact tables. Prefer simple aggregations over iterators when the question allows.
Margin % = DIVIDE ( [Gross Profit], [Total Sales] )
YTD Sales = TOTALYTD ( [Total Sales], 'Date'[Date] )
Orders with Sales = COUNTROWS ( FILTER ( VALUES ( 'Sales'[Order Number] ), [Total Sales] > 0 ) )
Avoid FILTER over a fact table when a column predicate or a relationship can do the job, and avoid nested iterators that multiply row-by-row work. Measure the query after each change; shorter DAX is not automatically faster.
Variables also make a measure easier to read and give the engine one place to evaluate a repeated subexpression. They do not guarantee a faster query on their own; the scan pattern still matters.
Reduce the work in visuals
Rendering time matters on lower-powered devices. A scatter chart with thousands of points, a table with conditional formatting on every cell, or a page with twenty visuals will feel slow even when the model is fast. Test on a typical device, not only a developer laptop.
- Limit each page to the visuals needed for one decision.
- Avoid tables and matrices with dozens of columns; use drillthrough or a detail page.
- Reduce slicer cardinality and turn off search where it is not needed.
- Use top N with a deliberate sort instead of plotting every category.
- Turn off interactions that are not useful; each cross-filter can trigger more queries.
- Put rarely used detail on a separate page rather than one dense canvas.
Refresh and the service
Incremental refresh, query folding, and a gateway close to the source reduce refresh time. Check that the gateway is not the bottleneck and that refreshes do not overlap. In the service, concurrency and capacity matter: a report that is fast in Desktop can queue behind other workloads.
| Layer | Check | Warning sign |
|---|---|---|
| Model | Column count, cardinality, data types | Large file and slow refresh |
| Relationships | Single direction, unique keys | Unexplained totals |
| DAX | Variables, column filters, no fact-table FILTER | High query time in Performance Analyzer |
| Visuals | Visual count, rows plotted, interactions | Slow display with fast query |
| Refresh | Folding, partitions, gateway | Refresh duration grows over time |
Frequently asked questions
Why is a report fast in Desktop but slow in the service?+
Desktop may use a local model with no network latency, a warm cache, and no competing workloads. In the service, gateway location, capacity load, and refresh state all affect response time. Test the published report with the same filters.
Does reducing visuals always improve performance?+
It often helps rendering, but the model and DAX may still dominate. Use Performance Analyzer to see where the time goes before deleting visuals.
Is DirectQuery slower than import?+
DirectQuery sends queries to the source at report time, so latency depends on the source, the query, and the network. Import usually answers faster but requires refresh and storage. The right choice depends on freshness and volume.
How is the slowest measure found?+
Use Performance Analyzer and sort by duration, then inspect the DAX query for the slowest visual. Focus on the measures that visual uses rather than every measure in the model.
Need help applying this?
Get help with Dashboards & BI.
Review the service scope or tell us what you are trying to improve. We will reply with a clear next step.
Free KPI definition templateRelated reading
Why dashboards get slow and how to fix them
A diagnostic guide to slow dashboards: separating query, transfer, and render time, then fixing data volume, model design, and page weight in order.
Power BI bookmarks and navigation patterns
Practical Power BI bookmark and navigation patterns: page switchers, view resets, drillthrough, button states, and the testing that keeps them usable.