A Power BI report page takes 30 seconds to render — how do you find which visual is responsible?

## Measure first The wrong answer to this question is a list of best practices. The right answer starts with instrumentation, because report slowness is almost always concentrated: one visual, or one measure, accounts for most of the wall clock, and the other nineteen are noise. **Performance Analyzer** ships in Power BI Desktop. You start recording, refresh the visuals, and get a per-visual log. Each entry breaks into three parts: - **DAX query** — time the semantic model spent producing the result set. This is the model's problem: measure complexity, cardinality, DirectQuery round-trips, or filters that cannot travel efficiently. - **Visual display** — time the visual spent rendering what came back. High values mean too many data points, a table with thousands of rows, a map with heavy shapes, or a custom visual with slow rendering code. - **Other** — preparation, waiting for other queries, and background work. A large "other" across many visuals usually means queuing: the page is asking for too much at once. Performance Analyzer also exposes the **DAX query text** each visual generated, and you can copy it out and run it in an external tool to time it in isolation. That is the standard escalation path once you know which visual is guilty. ## Reading the result The split is the diagnosis. *One visual, huge DAX query time.* The measure behind it is doing too much work — iterating a large table row by row, or a filter that cannot be pushed down. Look at that measure and the model behind it, not the canvas. *Many visuals, moderate DAX time each.* Nothing is individually broken; there are simply too many queries. The fix is layout: fewer visuals on the page, detail moved behind a drill-through page, and interactions turned off between visuals that do not need to talk, so a single click does not re-fire everything. *Long visual display with short query time.* The visual is being asked to draw too much. A table with tens of thousands of rows, a scatter chart with a huge number of points, or a custom visual that renders slowly. Aggregate before plotting, or replace the visual. *Slow only in the Service, fast in Desktop.* Now it is not the report layout. Look at storage mode, the gateway if one is in the path, capacity load and concurrent users — a DirectQuery page pays a source round-trip per visual per interaction, so the source system's concurrency is in play. ## What actually moves the needle Roughly in order of payoff for a slow *page*, once you know which visual is at fault: 1. **Fewer visuals per page.** The blunt instrument, and it works. Every visual is at least one query. Summary pages should be small; detail belongs behind drill-through. 2. **Turn off interactions you do not need.** Each click re-queries every interacting target, so a page where nothing filters anything unnecessary fires a fraction of the queries. 3. **Reduce what each visual asks for.** Fewer points, fewer columns in a table, top-N filters instead of unbounded lists, and no visual that dumps raw rows onto a summary page. 4. **Fix the guilty measure or model.** Simplify the DAX, remove needless iteration, and check that the model shape lets filters travel efficiently. Model design is the neighbouring topic, but the report page is where its cost becomes visible. 5. **Prefer import over DirectQuery where the requirement allows**, or introduce aggregations, when DAX time is dominated by source round-trips. ## Things candidates say that do not help "Buy more capacity" before measuring. Capacity helps a throughput problem; it does not rescue one visual issuing an expensive query, and it is an expensive way to avoid a diagnosis. "Convert measures to calculated columns." Sometimes right, often wrong, and never a blind rule — a calculated column costs model size and refresh time and is fixed at one grain. Cosmetic changes such as hiding the filter pane: no query is saved. ## Reporting the finding The senior habit an interviewer is listening for is a loop, not a list: measure with Performance Analyzer, identify the dominant visual, isolate its query, change one thing, re-measure, and record what the change bought. And know when the answer is not a tweak at all — a page that is a data extract in disguise, with a forty-column table of raw rows, should be a paginated report or an export, not a dashboard visual asked to draw the warehouse.