Diagnose why a Power BI report is slow before rewriting DAX or buying more capacity.

A slow Power BI report is an observed symptom, not a DAX diagnosis. The delay can occur while preparing visual queries, evaluating DAX, translating or executing DirectQuery, waiting on a gateway or source, queuing behind other visuals, rendering a visual, retrieving images, enforcing security, or competing for capacity. Rewriting a measure without identifying the dominant layer can change business results while leaving the user experience unchanged.

Datrick treats performance tuning as controlled engineering. We capture a reproducible interaction, preserve the result and filter context, locate the bottleneck, make one bounded change, and replay the same workload. AI can assemble evidence, explain model and DAX dependencies, rank suspicious patterns, and draft alternatives. It cannot replace a production measure, relationship, storage mode, or business definition without deterministic result comparison, review, deployment control, and rollback.

Define a reproducible performance contract

Do not baseline by opening a report once. Define the report, page, user or role, filter state, slicer action, drill path, browser or Desktop version, Service workspace, semantic-model version, storage mode, cache condition, time of day, capacity, data volume, expected result, and acceptable response time. Include cold and warm behavior where both matter. Repeat enough times to separate normal variation from a material change.

Microsoft Performance Analyzer records the time each visual takes and separates DAX query, DirectQuery, visual display, and other work. The exported JSON and copied DAX query make a useful starting point. Durations can include queueing because report operations share UI resources, so interpret the order and interaction rather than treating every number as isolated compute time.

Locate the slow layer before choosing a fix

Report and visual design

Every visual can issue queries, participate in interactions, and consume rendering time. Test whether the page requests too many visuals at once, contains expensive custom visuals, renders high-cardinality tables, loads remote images or maps, or triggers unnecessary cross-filtering. Use query reduction and interaction design where appropriate, but preserve the questions users need to answer. Removing information is not an optimization if users recreate it through exports and manual work.

DAX measures and filter context

Measure performance depends on the exact query and model context. Inspect expensive iterators, repeated expressions, context transitions, broad filters, virtual relationships, nested calculations, high-cardinality intermediate results, and operations pushed into the formula engine. Avoid generic rules such as “never use this function.” A function can be efficient in one filter context and expensive in another.

For each proposed rewrite, compare totals and detail across representative dimensions, no-selection and multi-selection states, missing values, period boundaries, inactive relationships, many-to-many paths, row-level security roles, and calculation groups. A faster wrong measure is a regression.

Semantic-model structure

A well-designed star schema reduces ambiguity and supports efficient filtering. Review fact and dimension grain, relationship cardinality and direction, snowflaking, role-playing dimensions, bridge tables, hidden technical columns, unused columns, data types, calculated columns, and column cardinality. Large text or identifier columns can increase model size even when they never appear in a report.

Model reduction can improve memory, refresh, and query behavior, but verify lineage and external consumers before removing objects. Excel connections, thin reports, paginated reports, APIs, and other semantic models may depend on fields not visible in the target report.

Import, DirectQuery, Direct Lake, and composite behavior

Storage mode determines where work executes and which constraints dominate. Import models depend heavily on model design, compression, and DAX execution. DirectQuery depends on generated queries, source design, network and gateway latency, concurrency, and round trips. Composite and hybrid models can cross storage engines and create unexpected paths. Direct Lake adds its own fallback and model considerations.

For DirectQuery, capture the generated source query and actual source plan where authorized. Check query folding, predicates, joins, indexes, statistics, partitions, result size, source concurrency, and gateway path. Reducing a DAX duration in Desktop is not enough if the Service still waits on an overloaded source.

Power Query and source preparation

Transformation choices affect refresh and sometimes interactive performance. Review folding boundaries, data-type conversions, row and column reduction, merge and group operations, parameterization, source views, and repeated queries. Push appropriate set-based work to capable sources, but do not duplicate business logic across unmanaged layers. Record where each transformation is owned and tested.

Service, gateway, network, and capacity

A report that is fast in Desktop and slow in the Service needs an environment comparison. Check deployed versions, user security context, gateway mapping, source route, region, browser rendering, cache, concurrent users, semantic model operations, and capacity timepoints. Use the Fabric Capacity Metrics app to determine whether the report was affected by shared overload or throttling. Do not rewrite DAX to compensate for a capacity incident.

Run an evidence-led optimization workflow

Use AI as an analyst, not an autonomous model editor

AI can summarize Performance Analyzer traces, map visual queries to measures, explain filter context, compare measure versions, group repeated patterns, identify likely high-cardinality drivers, draft source and model questions, and generate a test matrix. It is especially useful when evidence spans report, model, source, gateway, and capacity owners.

Keep production write access out of the analysis agent. Require exact artifact versions, evidence links, confidence, alternatives, and missing information. Never send business data, DAX, schema, queries, or user information to an unapproved model endpoint. Log prompts and outputs according to the engagement's data-handling policy.

Validate performance and business semantics together

Compare the same report page, interaction, filter state, role, data version, environment, and cache condition. Run multiple samples and report distributions, not the best run. Measure total user latency and the layer-specific change. If a query becomes faster but visual rendering or queueing dominates, the user may receive little benefit.

Build result controls before modifying DAX or relationships. Compare approved totals, detail samples, dimension slices, period boundaries, blanks, unknown members, subtotal behavior, and security roles. For source or Power Query changes, reconcile row counts, keys, duplicates, aggregates, and late data. For storage-mode changes, test freshness, concurrency, source impact, and failure behavior.

Observe after deployment during representative load. A Desktop improvement can disappear under Service concurrency. Confirm report latency, semantic-model query behavior, capacity CU, source load, gateway health, refresh duration, errors, and user feedback. Preserve before-and-after evidence and identify any demand shifted to another system.

Prioritize changes by user value and engineering risk

• User experience: page load, slicer response, drill, tooltip, export, mobile use, abandonment, and decision deadline.
• Query: DAX and DirectQuery duration, formula and storage-engine work, round trips, rows returned, cache behavior, and variability.
• Model: size, cardinality, unused data, relationship complexity, scan volume, storage mode, and shared-consumer impact.
• Environment: gateway and source latency, concurrency, capacity CU, throttling, network path, region, and deployed-version drift.
• Control: incorrect total, broken filter, RLS exposure, unsupported external consumer, refresh regression, source overload, and unapproved change.

Sequence high-confidence, high-user-impact changes with bounded risk first. Some issues need architecture work rather than a quick formula rewrite. Label temporary containment, permanent remediation, prerequisite data work, and capacity decisions separately so stakeholders understand what each change accomplishes.

Assess one critical report in one to three weeks

1. Select a report with measurable slowness, meaningful use, an accessible semantic model, and named business and technical owners.
2. Define representative interactions, security roles, data versions, cache conditions, business results, performance targets, and deployment environments.
3. Collect report, model, DAX, Power Query, source, gateway, Service, capacity, usage, change, and incident evidence.
4. Baseline total and layer-specific latency with Performance Analyzer and approved complementary diagnostics.
5. Rank visual, DAX, model, source, storage-mode, gateway, network, concurrency, and capacity contributors.
6. Design bounded remediations with expected impact, correctness controls, dependency analysis, effort, rollback, and owner.
7. Implement selected changes in a controlled copy and replay the matched result and performance test matrix.
8. Deliver prioritized findings, implementation changes where scoped, before-and-after evidence, release plan, monitoring, and maintenance guidance.

A one-report assessment can often finish in one to three weeks. Implementation can take two to six weeks when source changes, model redesign, storage-mode changes, shared semantic-model dependencies, or formal release controls are required. The engagement should end with measured findings and an approval-ready change plan, not a generic best-practice checklist.

Frequently asked questions

Official implementation references

• Microsoft Power BI Performance Analyzer
• Microsoft Power BI optimization guidance
• Microsoft Power BI star schema guidance
• Microsoft Power BI DirectQuery model guidance
• Microsoft Power BI report-level auditing guidance
• Microsoft Power BI DAX query view