Power BI performance tuning should start by identifying where time is being spent. For Microsoft PL-300, slow reports can come from visual design, DAX, relationship and model structure, source queries, refresh behavior, or capacity. Microsoft DP-600 extends that troubleshooting into larger Fabric semantic models and capacity-aware architectures.
The Optimize ribbon, Performance Analyzer, and DAX Query View provide a practical workflow: capture what a visual executes, inspect the generated DAX query, then decide whether the bottleneck belongs to the report, semantic model, or data source. Tuning without measurement often improves the wrong layer and can make a model harder to maintain without making users faster.
Measure the slow visual before changing the model
Performance Analyzer records how long visuals spend in DAX query execution, visual display, and other processing. Start recording, reproduce the slow interaction, and identify which visuals dominate the page. One slow custom visual or hidden visual can delay the entire experience even when most measures are efficient.
Test with the same filters and data volume users experience. Record cold and warm behavior because caching can make repeated developer tests look faster than the first experience users receive. Compare desktop testing with the Power BI service when capacity, gateways, and network paths differ from the local authoring environment. A development page with one selected customer may hide a query that becomes expensive when users choose All. Capture several representative interactions so tuning targets the recurring bottleneck rather than one accidental outlier.
Use DAX Query View to inspect the generated query
Performance Analyzer can copy a visual query or open it in DAX Query View. Running the query outside the report canvas separates semantic-model execution from rendering and interaction. This helps determine whether the issue is DAX/model performance or the complexity of the visual itself.
Keep a before-and-after query timing record for meaningful changes. Copy representative visual queries into DAX Query View and save them as a small regression suite. This makes it easier to verify that a model change improves several important queries instead of accelerating one visual while slowing another. DAX Query View is also useful for testing measures and inspecting results without repeatedly rebuilding a visual. Treat it as a diagnostic workspace, not only as an advanced authoring feature.
Reduce model size and cardinality
Columnar storage performs best when the model contains only useful columns with appropriate data types and manageable cardinality. Remove unused high-cardinality text, GUIDs, timestamps, and technical columns from the semantic model when reports do not need them. Split datetime into date and time only when the analysis requires both. Review model granularity before tuning individual measures, because unnecessarily fine-grained facts and high-cardinality columns increase memory pressure and the amount of data the engine must scan.
Avoid calculated columns that duplicate logic better handled upstream or by a measure. Choose low-cardinality numeric and dictionary-friendly data types where possible, and avoid storing descriptive columns in large fact tables when the same attribute belongs in a dimension. Compression quality can change dramatically with cardinality and duplication. Every imported column consumes model memory and can affect compression. A smaller star schema usually scans less data, refreshes faster, and leaves more capacity for concurrent queries. Use VertiPaq-oriented tooling and model statistics where available to identify the columns consuming the most memory. High-cardinality strings in a large fact table often deliver little analytical value relative to their storage cost.
Star-schema design improves filter efficiency
Dimensions with unique keys filtering fact tables through one-to-many single-direction relationships give the engine a predictable path. Ambiguous relationships, widespread bi-directional filtering, and fact-to-fact relationships can complicate query plans and make DAX harder to reason about.
Fix model structure before adding complex DAX workarounds. Check inactive relationships, many-to-many bridges, and duplicated dimension keys when filter propagation appears slow or unpredictable. A model with clear one-to-many paths allows the storage engine to do more efficient work and makes query plans easier to interpret. If many measures depend on CROSSFILTER or TREATAS to reproduce normal dimensional behavior, the relationship design may be the real source of complexity. Good performance and understandable semantics often improve together. Remove unnecessary bi-directional relationships and ambiguous paths, and prefer dimensions that filter facts predictably. This reduces both engine work and the amount of defensive DAX authors need to write around the model.
Optimize DAX by reducing repeated work
Build measures from reusable base measures and use variables when an expensive expression would otherwise be evaluated repeatedly. Prefer simple filter arguments when they express the business rule, and avoid iterating large fact tables row by row when a storage-engine aggregation can produce the same result more efficiently.
Performance tuning must preserve correctness. Inspect expensive iterators, nested CALCULATE patterns, FILTER over large tables, and repeated DISTINCT or VALUES operations, but change them only after understanding the semantic effect. Variables can improve readability and sometimes reduce repeated evaluation, yet the engine still needs a sound model to perform well. A faster measure that changes total behavior or ignores required filters is not an optimization. Maintain small test cases for key calculations so refactoring can be validated against known results.
DirectQuery shifts the bottleneck to the source
In DirectQuery models, Power BI generates queries against the external data source. Keep transformations foldable where possible and inspect the source SQL or native query for filters, joins, and aggregation pushdown. If Power Query materializes large intermediate results locally, report tuning must start with the transformation path rather than DAX. Source indexing, statistics, concurrency, gateway latency, query folding, and database capacity become part of report performance. Use Performance Analyzer to obtain the generated query and inspect it with the source platform’s normal database tools.
The Optimize ribbon can pause visual queries while authors make several changes and offers query-reduction options for DirectQuery scenarios. Apply buttons for slicers and filters can reduce the number of round trips when users make several selections. Query reduction is especially valuable when the source is remote or charges per query. This improves authoring efficiency and can reduce unnecessary source load, but it does not fix a poorly indexed source or an overly complex report query.
Design report pages for fewer expensive queries
Each visual can generate one or more queries. Pages with many visuals, high-cardinality tables, synchronized slicers, custom visuals, and cross-highlighting can create substantial work before the user receives a complete page. Remove visuals that do not answer a distinct business question and avoid rendering large detail tables by default.
Use drillthrough, tooltips, bookmarks, or separate detail pages to defer expensive detail until the user asks for it. Limit large tables and matrices, reduce unnecessary conditional formatting, and be cautious with custom visuals whose rendering time dominates the query. Visual design is part of the performance budget. Performance is part of report design: a focused page with clear interactions is often faster and easier to understand than a dashboard that tries to show every metric at once. Use user telemetry or report-usage evidence to identify pages and interactions worth optimizing first; tuning an unused report can consume engineering time without improving the real experience.
Refresh performance is a separate optimization path
A report can query quickly and still have an unacceptable refresh window. Refresh bottlenecks can come from source throttling, non-folding transformations, gateway saturation, calculated-column processing, large partitions, or capacity contention. Measure each stage instead of treating refresh as one opaque duration. Review Power Query folding, incremental refresh, source throughput, transformation placement, partitioning, and model size. Move reusable heavy transformations upstream when the data platform can perform them more efficiently and consistently.
Monitor refresh duration and memory as the model grows. Incremental refresh can limit processing to recent partitions, while aggregations can accelerate common queries over large detailed data. Validate that partition and aggregation logic matches business grain so optimization does not create stale or inconsistent results. A full refresh that barely fits today may fail after another month of data. Capacity planning should account for both interactive query load and refresh operations because they can compete for the same resources.
Tune systematically and keep evidence
A useful tuning sequence is visual measurement, DAX/query inspection, model review, source review, and capacity review. Change one major factor at a time and record the effect. Capacity metrics can reveal CPU, memory, throttling, or concurrency pressure that is invisible inside a single report. If many reports slow down together during peak hours, model-level tuning may help, but the shared capacity or refresh schedule may be the dominant constraint. Without a baseline, teams can spend hours rewriting DAX while the real problem is a slow DirectQuery source or one overloaded report page.
Performance work should leave the model easier to operate. Keep a small performance regression pack of representative report pages, DAX queries, refresh operations, and concurrency scenarios. Run it before major releases so the team can catch a slow model or source change before it reaches the broad user population. Document high-impact measures, source dependencies, storage mode, refresh strategy, and known capacity limits. The goal is not a one-time fast screenshot; it is a semantic model and report experience that remain responsive as data and usage grow. Re-run key benchmarks after major data-volume growth, relationship changes, storage-mode changes, or DAX refactoring so performance regressions are detected before users normalize slow behavior.
Keep a small performance baseline for representative reports and measures. Record model size, refresh duration, visual render times, expensive DAX queries, and capacity conditions before a tuning change. Without that baseline, a faster test run may simply reflect warmer caches or lighter concurrency. Repeat the same workload after the change so the team can attribute improvement to the model or query modification rather than to a different test environment.