Power BI Slow Visuals: Find the Bottleneck First

Start a slow Power BI report investigation by recording one repeatable interaction in Performance Analyzer. Separate the query, visual display, and other time before changing DAX, redesigning the model, or requesting more capacity. Then change one thing and confirm both the result and the interaction time.

This guide concerns interactive report pages. A slow Import refresh is a different operation. The worked incident and timings below are fictional illustrations, not benchmark results or a promise about your model. They show how to decide what evidence to collect and what a useful before-and-after check contains.

Record the exact slow reader action

Replace “the dashboard is slow” with a reproducible statement: “In the published support report, selecting September and expanding the team matrix takes about twelve seconds for a Viewer.” Record the page, visual, filters, identity or security role, storage mode, model version, and time of day. Preserve the previous working version if a recent change may matter.

Define success with the report owner. A teaching target such as “the team comparison appears within two seconds on the agreed test device” is useful only when the device, network, filters, and concurrency assumptions are recorded. A universal row-count or latency threshold cannot diagnose a particular report.

Keep private model files and exported queries in an approved location. They can expose business logic, table names, and filter values. A performance investigation does not require uploading the model to an external AI service.

Capture one interaction with Performance Analyzer

In an editable report, open Performance Analyzer, start recording, and perform the slow interaction once. Expand the affected visual's timing details. Where available, refresh or analyze that visual separately, and export the recording so the baseline is reproducible. Microsoft documents the supported Desktop and web experiences in its Performance Analyzer guide.

The categories narrow the next investigation: DAX query concerns retrieving the result; Visual display concerns drawing it; Other includes remaining work such as preparation and waiting. A large Other value is not a diagnosis of insufficient capacity. Visual activity can overlap, so adding all visual durations does not give a reliable page-load time.

Repeat the same interaction three times after an initial run. Label the initial run separately because caches can change the result. Keep individual measurements as well as a median. Avoid comparing a new, unfiltered first load with a previously cached, narrowly filtered click.

Follow the evidence to the right layer

For refresh failures, use the Desktop-versus-service refresh guide. Report interaction and model refresh may influence each other under contention, but they are not interchangeable measurements.

Use a small fixture to protect the answers

Before replacing a measure or changing a display, record expected values. Import this fictional CSV as Sales, with text identifiers and fixed-decimal Revenue and Cost. One row is one order.

OrderID,Team,CustomerID,Revenue,Cost
O1,North,A,100,60
O2,North,B,200,120
O3,North,A,50,40
O4,South,A,300,150
O5,South,C,400,200
O6,South,D,150,90

Create these separate measures:

Revenue = SUM ( Sales[Revenue] )

Cost = SUM ( Sales[Cost] )

Profit = [Revenue] - [Cost]

Margin % = DIVIDE ( [Profit], [Revenue] )

Customers = DISTINCTCOUNT ( Sales[CustomerID] )

The expected North result is revenue 350, profit 130, margin 37.14%, and two customers. South has revenue 850, profit 410, margin 48.24%, and three customers. Overall revenue is 1,200, profit 540, margin 45%, and four unique customers. Customer A appears in both teams, so adding the team customer counts would incorrectly produce five.

Test each team, the combined total, Customer A alone, and no matching orders. Customer A's revenue is 450 and profit is 200. These values are independent arithmetic checks of this fixture; they are not evidence that a DAX engine executed the measures. Use the totals guide when an optimization changes ratio or distinct-count semantics.

Worked incident: rendering dominates the delay

In this fictional incident, the team-review page opens a detailed matrix with thousands of displayed order rows, several conditional formats, and nine additional visuals. Readers normally need a two-team comparison before investigating individual orders. The initial investigation therefore measures the existing view and a proposed summary-plus-detail route.

The author keeps the same Revenue, Profit, Margin %, and Customers measures. The overview uses Team, while drillthrough shows OrderID for the selected team. The owner accepts the revised task: compare teams, then open the needed detail. The author verifies the fixture's team totals and checks that North drillthrough lists O1–O3 while South lists O4–O6.

This change deliberately changes the overview's displayed grain. It is appropriate only because the owner agrees that full detail remains available through the new route. A hidden Top N filter that silently removes required records would fail that acceptance test. Microsoft's optimization guidance covers visual volume, filtering, custom visuals, model design, and environmental factors.

When query time dominates, isolate the expensive expression

Duplicate the affected page in a test copy. Keep one visual with its original filters, then replace the values with a basic row count or sum. Restore measures one at a time. If one measure causes the jump, compare its behavior on a single team and on the full selection before rewriting it.

Check whether an iterator evaluates at the intended business grain, whether a measure removes a useful filter, and whether the grouping requests far more combinations than the reader needs. An apparently simple visual can still ask the model to perform expensive work. Conversely, a complex-looking measure may be acceptable when it processes a small, well-filtered population.

If your approved tooling supports deeper query analysis, retain the generated query and inspect its execution evidence. Do not infer a universal root cause from one timing category. Source behavior also matters for DirectQuery: compare the corresponding source request with the report interaction. A fast local Import copy is not an equivalent performance baseline for a deployed DirectQuery model.

Check the deployed environment without guessing

When the same deployed interaction varies by time, ask the capacity administrator to correlate its timestamp with other workloads and any recorded throttling. The Fabric Capacity Metrics compute page provides utilization, operation, and throttling views for supported capacity scenarios. Availability and permissions depend on the environment; an author without those metrics needs the administrator's evidence.

Compare the actual consumer's security context, storage mode, and selected population. A small region-specific test may differ from an administrator viewing every region. Record concurrent workload conditions, but arrange any deliberate load test with the service owner and an approved test environment.

Before accepting the change, repeat the original reader action three times, retain the individual timings, verify the control totals and detail IDs, and test another useful filter. Keep the version and rollback path. The worked report-layout example helps decide which details belong on the overview and which belong in an investigation view.

FAQ

Does a long Other duration mean I need more capacity?

No. Isolate the visual and page workload, then compare the deployed environment. Use capacity evidence to establish contention or throttling rather than treating a timing label as proof.

What if Copy query fails or crashes?

Save the report version and try exporting the recording. Reduce the reproduction to one visual in a test copy. Retain the error and exact steps for support instead of replacing the shared model repeatedly.

Should I optimize a report that is fast in Desktop?

First reproduce the consumer's deployed route. Different model connections, security contexts, filters, and concurrent workloads can change performance. A local result is one comparison point, not proof of the published experience.