Power BI Performance Analyzer is a built in diagnostic pane in Power BI Desktop. It records how each visual behaves as a report page loads. It captures visual display time, DAX query time, and other process time for each interaction. The results are shown as a timing trace you can review or export, so you can see exactly where a page is spending its time.
If you want to understand how this feature fits into your Power BI performance tuning process, or why a particular page or visual feels slower than it should, you have come to the right place. In this article, we will walk through what Power BI Performance Analyzer is, how to enable and use it in Power BI, and how its timings behave in everyday report use.
So, without further ado let us get to it.
What is Power BI Performance Analyzer?
Power BI Performance Analyzer is a built in diagnostic pane in Power BI Desktop that shows you how long each visual and query takes when a report page loads. It is basically a stopwatch inside the report that breaks total load time into smaller pieces you can inspect.
When you open the pane, Power BI Performance Analyzer lists every visual on the active page. It then records what happens when the page refreshes. It also tracks how visuals respond when you change filters and slicers.
For each visual, it shows three main timings: DAX query time, Visual display time, and Other time (things like background processing and layout)
These numbers update while you click around the report. Because of that, you can see how a page behaves when you move slicers, switch bookmarks, or trigger a drill through. You can also export the results if you want to review them outside Power BI Desktop.
Right now, Performance Analyzer only lives in Power BI Desktop, not in the Power BI Service. You turn it on from the View tab by selecting Performance Analyzer. The pane then appears on the right side of the report canvas, ready to start recording.
For an overview of the basics, read how to use Power BI.
How to use Power BI Performance Analyzer
It’s actually quite simple to use Power BI performance analyzer. You open the pane, start recording, interact with the report, and then review or export the results.
Here is the detailed steps to help you use that Power BI Desktop.
1. Open the Performance Analyzer pane
First, you need to make the Performance Analyzer pane visible in your report. You will use this pane for all the recording and review steps.
- In Power BI Desktop, go to the Optimize ribbon.
- Select Performance Analyzer.
- The Performance Analyzer pane appears on the right side of the report canvas.
Keep the pane visible while you work, because all the actions you want to measure start from here.
2. Start recording
Next, you have to tell Power BI when to begin timing your report actions. This gives you a clean starting point for the test.
- In the pane, click Start recording.
- From this point, Power BI begins to log what happens on the active page.
Every action you take is now tracked. This includes changing slicers, adjusting filters, switching pages, and expanding or collapsing hierarchies.
3. Interact with the report
Once recording is on, you should use the report the way a real user would. The goal is to capture timings for common journeys, not just a single click.
With recording turned on:
- Change slicer values
- Apply or clear filters
- Move between report pages
- Drill down or drill through in visuals
Performance Analyzer lists each visual in the order it loads and updates the timings while you click around. This helps you see which actions trigger the longest response times.
If you want to refresh everything on the page in one go, click Refresh visuals in the pane. Power BI reloads all visuals on the current page and captures performance data for each one.
4. Stop recording and review the results
After you have captured a few realistic actions, it is time to pause and look at the data. This is where you begin to see which visuals are slow.
When you have done enough interactions, click Stop recording. The pane now shows a list of visuals and their timings for the actions you just performed.
At this stage you can:
- Expand each visual in the pane to see its detailed timings
- Sort the list to bring the slowest visuals to the top
- Clear the log if you want to run a fresh test
You will use these timings in the next section when you interpret what each part means and decide what to fix.
5. Export the performance data (optional)
Sometimes you may want to keep a record of your tests or share them with someone else. In that case, exporting the Performance Analyzer results is helpful.
If you want to keep a record of your test, click Export in the Performance Analyzer pane. Power BI creates a JSON file with the results.
You can store this file for later comparison, share it with a colleague, or load it into another tool for deeper analysis. This is useful if you are testing several versions of the same report or tracking performance over time.
For shaping and reusing source data, see our guide on Power BI dataflows.
Using analyzer results to fix slow Power BI dashboards
Once you have run Power BI Performance Analyzer, the timings become your map. You do not have to fix everything at once. Instead, you look at which part of the duration is high, then apply a matching fix. It is basically an “if this is high, then do that” way to solve Power BI performance issues.
Here are some of the common problems you might run into, and how to tackle each one.
If visual display time is high then reduce visual complexity
If visual display time is high, then the slow part is how Power BI renders the visual, not how it gets the data. The query may finish in time, but drawing the visual on screen takes too long.
This is common with large or complex visuals, custom visuals with heavy graphics, visuals that show thousands of points, or table and matrix visuals with too many rows and columns.
You can improve this by:
- Reducing the number of rows in tables and matrices with Top N filters, for example showing the top 500 records instead of every row.
- Cutting the number of columns in matrix and table visuals so there is less to calculate and render.
- Moving very detailed visuals, such as dense maps or big tables, to separate drill through pages so they only load when users ask for detail.
- Simplifying or removing custom visuals that look nice but add a lot of rendering overhead.
- Combining several small visuals into one card or matrix where it makes sense, rather than loading many separate visuals on one page.
After these changes, you should see visual display time drop and the page will feel lighter to use.
If DAX query time is high then optimise your DAX and data model
If DAX query time is high, then the bottleneck is in your measures or model design. Power BI is spending most of its time evaluating DAX before it can even start drawing the visual.
This is common when you use complex iterators over large tables, work with high-cardinality columns, or build deep nested logic inside one measure.
You can improve this by:
- Replacing row by row iterators like SUMX over large tables with set based functions such as SUM where possible.
- Using variables to cache intermediate results so DAX does not repeat the same calculation.
- Filtering on specific columns rather than whole tables to shrink the amount of data in scope.
- Swapping high-cardinality text columns, like customer names, for numeric surrogate keys such as customer IDs.
- Simplifying long chains of IF into SWITCH where it is easier for the engine to evaluate.
- Avoiding unnecessary context transitions that force DAX to recalculate values more often than needed.
After you tune the key measures and relationships, DAX query time should fall into a more acceptable range.
If “Other” duration is high then reduce page and interaction overhead
If “Other” duration is high, then the delay usually comes from background coordination, not one specific visual or query. Power BI is preparing queries, waiting for other visuals to finish, or managing many interactions at once.
This often happens on busy pages with many visuals competing for resources, lots of slicers, or complex interactions between visuals.
You can improve this by:
- Reducing the number of visuals on a page, for example going from fifteen or twenty down to six or eight key visuals.
- Consolidating filters and slicers instead of showing a long row of separate slicers.
- Moving non essential visuals to separate pages or drill through reports so they do not load on every visit.
- Using bookmarks to present common filter states instead of exposing every slicer at the same time.
Once the page has fewer moving parts, “Other” time usually drops and the whole dashboard loads more smoothly.
If filter or slicer interactions are slow then simplify filter relationships
If filter or slicer interactions are slow, then the issue is how filters flow through the model and visuals. Every change may be triggering more updates than you actually need.
This is common when you have many interdependent slicers, complex relationships, or visuals that cross filter each other in several directions.
You can improve this by:
- Converting slicers to dropdowns or single selection controls so fewer combinations are active.
- Adding an Apply button so users can set several filters and apply them in one batch, rather than updating on every click.
- Reducing the number of slicers on the page by combining related filters into a simpler hierarchy.
- Turning off cross filtering between visuals that do not need to interact.
- Using the newer card visual to show several metrics in one container, which reduces the number of visuals that respond to each filter change.
After you simplify filter relationships, slicer changes should feel more responsive and “Other” time after interactions should be lower.
If matrix or table visuals load slowly then limit detail and tune measures
If matrix or table visuals load slowly, then the visual is usually trying to do too much at once. It may be pulling a lot of rows and columns and running several heavy measures for each one.
This is common when you show unfiltered detail, use complex DAX inside the matrix, or rely on a model that is not well structured.
You can improve this by:
- Applying Top N limits so the visual shows a manageable number of rows, such as a few hundred instead of tens of thousands.
- Reducing the number of columns so Power BI has fewer values to calculate per row.
- Optimising the measures used in the visual with the DAX performance steps described earlier.
- Making sure the data model has clear relationships and sensible normalisation, so queries can run efficiently.
- Using drill through or detail pages for deep dives, instead of loading all detail on the main dashboard page.
- Checking that measures inside the matrix are not duplicating filters or using inefficient patterns that you could simplify.
With those changes in place, matrix and table visuals should become more responsive, and overall Power BI performance issues on that page will be easier to manage.
Best Practices for Preventing Slow Power BI Dashboards
Performance Analyzer is great for troubleshooting, but it is even better if your dashboards feel fast from day one. A few habits in your model, visuals, and page design can prevent most Power BI performance issues before they show up.
Here are five practical best practices to build into your process.
- Keep pages lean: Limit each page to a small set of key visuals. Fewer visuals mean fewer queries, less coordination work, and faster load times for your users.
- Design a clean data model: Aim for a simple star schema with clear relationships. Avoid unnecessary many to many relationships and large, unneeded columns, because they make every query heavier.
- Optimise DAX early: Keep measures as simple as possible, use variables, and avoid row by row iterators on large tables. If a measure feels complex, test it in Performance Analyzer before you roll it out to every visual.
- Control filters and slicers: Use only the slicers you really need, prefer dropdowns or single selection where you can, and turn off cross filtering between visuals that do not need to interact. This reduces background work every time someone changes a filter.
- Test with realistic data and journeys: Always test dashboards with production sized data and typical user clicks, not just a small sample. Run Power BI Performance Analyzer during these tests so you can spot slow patterns early and adjust the design before release.
If you build these habits into your reports, performance analyzer becomes a final check, not a constant fire extinguisher for slow dashboards.
A Few Takeaways Before You Go
Power BI Performance Analyzer helps you see what slows your dashboards. It breaks each visual’s load into parts, which makes it easier to identify whether the delay comes from DAX, rendering, filters, or the number of visuals on the page. When you review these timings, you get a direct view of how the report behaves and what needs adjustment.
But keeping dashboards fast is not always simple. Troubleshooting DAX, managing visuals, and maintaining a solid data model can be time-consuming, especially when multiple reports grow at the same time.
That’s where Nexalab can help.
Nexalab is a Power BI consultant. We help teams diagnose the root cause of slow dashboards, redesign data models for better efficiency, tune DAX measures, and simplify visual layouts without losing insight. The goal is to create a reporting setup that loads quickly, scales with your data, and stays reliable long term.
Book a free consultation with Nexalab to improve your Power BI dashboards.
