Using Performance Analyzer to Identify Slow Visuals in Power BI

Course: Microsoft Power BI Training

Topic: Using Performance Analyzer to Identify Slow Visuals

Course Link: Microsoft Power BI Training – JustAcademy

Demo Link: Register for a Free Course Demo

JustAcademy Website: Visit JustAcademy

1. Introduction to Performance Analyzer

Power BI is a business intelligence platform used to transform raw data into interactive reports, dashboards, and visualizations. However, a report may become slow when it contains complex DAX measures, large datasets, inefficient data models, numerous visuals, or expensive visual interactions.

Performance Analyzer is a built-in feature in Power BI Desktop that helps report developers measure how long report visuals take to load and update. It records performance information for individual visuals and breaks down the time spent on different operations.

By using Performance Analyzer, developers can identify which visuals are responsible for slow report performance and investigate whether the delay is related to DAX query execution, DirectQuery processing, visual rendering, or other operations.

1.1 Why Performance Analyzer Is Important

• Identifies visuals that take the longest to load.
• Helps distinguish query delays from rendering delays.
• Supports investigation of slow DAX measures and queries.
• Helps optimize report pages containing multiple visuals.
• Improves the user experience when interacting with filters and slicers.
• Provides measurable evidence before and after performance optimization.
• Helps developers prioritize the most expensive report elements.

1.2 What Is a Slow Visual?

A slow visual is a chart, table, matrix, card, map, or other report element that takes noticeably longer than expected to display or refresh its data.

For example, a report page might contain five visuals. Four visuals load quickly, but a matrix containing detailed sales calculations takes several seconds to update. Performance Analyzer helps isolate that matrix so the developer can investigate its queries, measures, and rendering behavior.

2. Understanding the Power BI Performance Analyzer

Performance Analyzer records timing information for visuals as Power BI loads or updates them. The results appear in a dedicated pane in Power BI Desktop.

2.1 Main Components

2.2 Where to Find Performance Analyzer

1. Open your Power BI report in Power BI Desktop.
2. Select the Optimize ribbon, where Performance Analyzer is available in supported versions of Power BI Desktop.
3. Open the Performance Analyzer pane.
4. Expand or position the pane so you can view the recorded results.
5. Start recording before refreshing visuals or interacting with the report.

Note: The ribbon layout can vary between Power BI Desktop versions. If you cannot find Performance Analyzer in the Optimize ribbon, check the available performance-analysis options in your installed version.

3. Understanding Performance Analyzer Timing Categories

Performance Analyzer divides visual update activity into timing categories. These categories help developers understand whether the bottleneck is associated with data retrieval, calculations, rendering, or other processing.

3.1 DAX Query

The DAX Query category measures the time Power BI spends executing the DAX query associated with a visual.

When a visual displays aggregated sales, profit, customer counts, or other calculated values, Power BI generates queries to retrieve the necessary results from the semantic model.

A long DAX Query duration may indicate:

• Complex DAX expressions or nested calculations.
• Measures that perform expensive iterator operations.
• Large numbers of groups or categories in a visual.
• Inefficient filter propagation or relationship design.
• High-cardinality columns used in grouping.
• A large amount of data being processed by the model.

Example: A matrix displays sales by customer, product, region, and month. If it generates a large number of groups and evaluates several complex measures for every group, its DAX query may take longer than a simple sales card.

3.2 DirectQuery

The DirectQuery category is relevant when a visual uses a DirectQuery source. It represents time associated with querying the underlying data source through the DirectQuery pathway, as reported by Performance Analyzer.

Delays may be caused by:

• Slow database queries.
• Missing or ineffective database indexes.
• Large source tables or expensive joins.
• Network latency between Power BI and the source.
• Source-system workload or concurrency.
• Queries that cannot be efficiently translated into source operations.

DirectQuery timing should be interpreted together with the other timing categories. It is not a universal category for Import-mode models, and the precise breakdown depends on the model and operation.

3.3 Visual Display

Visual Display represents time spent rendering the visual in the report interface. After data is available, Power BI still needs to display the result as a chart, table, matrix, or another visual.

Visual rendering can become expensive when a visual contains:

• Thousands of rows or many data points.
• Numerous labels, markers, and data labels.
• Complex conditional formatting.
• Multiple series or categories.
• Large tables and matrices with extensive formatting.
• Complex visual configurations or custom visual behavior.

If Visual Display accounts for a substantial portion of the duration, investigate the visual's design and the amount of information it must render rather than assuming the DAX measure is the main problem.

3.4 Other

The Other category captures additional processing time that does not fall into the primary displayed categories. Depending on the visual and operation, it may include work associated with preparing or coordinating the visual update.

If Other accounts for a large portion of the total, investigate the visual's overall behavior, its dependencies, and the context in which it is updated. Do not assume that this category identifies a single specific cause.

3.5 Evaluating the Categories Together

4. Step-by-Step Process for Using Performance Analyzer

Step 1: Open the Power BI Report

Open the report in Power BI Desktop. Select the report page where users have noticed slow loading, delayed slicers, or unresponsive interactions.

Before measuring performance, save your report and note which page and visual appear slow. This provides a clear starting point for your investigation.

Step 2: Open Performance Analyzer

1. Navigate to the Optimize ribbon.
2. Select Performance Analyzer.
3. Confirm that the pane is visible.
4. Clear existing results if you want to start a fresh test.

Step 3: Start Recording

Click Start recording in the Performance Analyzer pane. Power BI will begin capturing supported visual performance events.

Starting the recording before a refresh or interaction is important because otherwise you may miss the operations you intended to measure.

Step 4: Refresh the Visuals

Use the Refresh visuals control in Performance Analyzer to initiate a refresh of report visuals and capture their performance.

Wait until the visuals finish updating. The pane should display entries for the recorded visual operations, including their timing information.

Step 5: Inspect the Recorded Results

Review the visual entries and compare their durations. Expand individual entries to inspect the timing categories.

Look for visuals with unusually high total durations or a particular timing category that dominates their update time.

Step 6: Identify the Slowest Visual

Compare visuals under the same test conditions. For example, if a sales card takes a fraction of a second but a detailed matrix takes several seconds, the matrix deserves closer investigation.

Do not rely only on the total duration. Check whether the delay is mainly caused by query execution, DirectQuery activity, rendering, or additional processing.

Step 7: Investigate the Relevant Query

Expand the slow visual's entry and inspect its DAX Query information. Where the interface offers the Copy query action, copy the query for further analysis.

You can use the copied query in an appropriate query-analysis workflow, such as DAX Studio, to investigate query behavior in more detail. Depending on the model, additional tools may be needed to examine storage-engine and formula-engine activity or source database performance.

Step 8: Optimize the Visual or Model

Use the evidence from the recording to select a targeted optimization. Examples include simplifying a measure, reducing the number of displayed categories, removing unnecessary columns from a matrix, or improving the underlying data model.

Step 9: Record Performance Again

Clear or separate the earlier results, start a new recording, and repeat the same refresh or interaction after the change.

Compare the results to determine whether the optimization improved performance. Keep the test conditions consistent so the comparison is meaningful.

5. Practical Example: Finding a Slow Sales Matrix

Consider a Power BI sales report containing the following visuals:

• Total Sales card.
• Total Profit card.
• Sales by Region bar chart.
• Monthly Sales line chart.
• Sales by Customer and Product matrix.

Users report that the page takes too long to respond when they select a region slicer. You open Performance Analyzer and record a visual refresh under the same conditions.

5.1 Sample Recorded Results

The following values are illustrative examples for learning purposes, not measurements from an actual report.

5.2 Interpreting the Results

The Customer and Product Matrix takes 2,600 milliseconds, or 2.6 seconds, in this illustrative measurement. Its DAX Query category accounts for most of the recorded duration.

This suggests that query execution should be investigated first. However, the 620 milliseconds associated with Visual Display also indicates that rendering may contribute to the delay.

5.3 Recommended Optimization Actions

1. Review the DAX measures used in the matrix.
2. Remove columns that are not necessary for the user's analysis.
3. Reduce the number of rows and grouping combinations where appropriate.
4. Check whether complex calculated expressions can be simplified.
5. Review relationships, data types, and model design.
6. Consider whether a summary table or a different visual design would better support the reporting requirement.
7. Repeat the performance test to confirm the improvement.

6. Using Performance Analyzer to Investigate Slow DAX Measures

DAX measures calculate values dynamically based on the filter context of a visual. A poorly designed or unnecessarily complex measure can increase query execution time, particularly when evaluated over many rows or groups.

6.1 Example of a Basic DAX Measure

Total Sales = SUM(Sales[SalesAmount])

This measure calculates the sum of the SalesAmount column in the Sales table. In a well-designed model, it is often straightforward to evaluate.

6.2 Example of a More Complex Measure

Sales Above Threshold =
SUMX(
    FILTER(
        Sales,
        Sales[SalesAmount] > 1000
    ),
    Sales[SalesAmount]
)

This example iterates over rows that satisfy a condition. Its performance depends on factors such as table size, filter context, storage-engine optimization, and the surrounding model.

It is not automatically slow simply because it uses SUMX or FILTER. The correct approach is to measure the actual query and investigate its behavior before rewriting it.

6.3 Techniques for DAX Optimization

• Prefer simple aggregations when they meet the business requirement.
• Reduce unnecessary row-by-row iteration.
• Use variables to make repeated expressions clearer and potentially avoid repeated evaluation where appropriate.
• Avoid unnecessary context transitions and overly complex filter expressions.
• Use appropriate star-schema modeling and relationships.
• Reduce unnecessary high-cardinality grouping in visuals.
• Test any rewritten measure against the original results to confirm correctness.

6.4 Example Using Variables

Profit Margin % =
VAR TotalSales =
    [Total Sales]
VAR TotalProfit =
    [Total Profit]
RETURN
    DIVIDE(TotalProfit, TotalSales, 0)

Using variables improves readability and can make complex measures easier to maintain. Performance improvements depend on the expression and evaluation context, so the measure should still be tested rather than assumed to be faster.

7. Identifying Visual Rendering Problems

Not every slow visual is caused by DAX. A query may return its results quickly, while Power BI still needs considerable time to render a large or complex visual.

7.1 Common Rendering Problems

• A matrix contains too many rows and columns.
• A chart displays a large number of categories or data points.
• Data labels are enabled for thousands of points.
• Conditional formatting creates additional complexity.
• Several visuals contain overlapping or redundant information.
• A custom visual has substantial rendering overhead.

7.2 Methods to Improve Visual Rendering

1. Display only the fields required for the analysis.
2. Use Top N filters when users need to focus on the most important categories.
3. Apply drill-down or drill-through instead of displaying every detail at once.
4. Limit unnecessary data labels and markers.
5. Simplify conditional formatting where possible.
6. Choose an appropriate chart type for the data.
7. Evaluate whether a standard visual performs better than a complex custom visual.

Example: Instead of displaying every customer and product in one matrix, create a summary by region and product category. Allow users to drill down into individual customers when more detail is required.

8. Performance Analyzer and Slicers

Slicers allow users to filter report data interactively. When a slicer selection changes, Power BI may need to recalculate and redraw multiple visuals on the page.

8.1 Why Slicers Can Make Reports Slow

• A slicer affects many visuals simultaneously.
• Several visuals use complex measures that must be recalculated.
• The slicer filters high-cardinality columns.
• The report contains expensive visual interactions.
• DirectQuery visuals trigger slow source queries.

8.2 How to Test Slicer Performance

1. Start a Performance Analyzer recording.
2. Change one slicer selection.
3. Wait for affected visuals to finish updating.
4. Inspect the recorded entries for the interaction.
5. Identify which visuals account for the greatest delay.
6. Review the relevant query and visual configuration.
7. Repeat the same interaction after optimization.

8.3 Managing Visual Interactions

Use Power BI's Edit interactions feature to control whether a slicer filters, highlights, or does not affect specific visuals, where appropriate.

Disabling unnecessary interactions can reduce work during user interactions. However, do not disable a meaningful filter relationship merely to improve speed; confirm that the report continues to satisfy its analytical requirements.

9. Performance Analyzer with Import and DirectQuery Models

9.1 Import Mode

In Import mode, data is loaded into the Power BI semantic model. Visual queries are generally evaluated against the in-memory model, although the full report experience still includes query processing and rendering.

For Import models, investigate DAX Query time, model size, relationships, cardinality, and the complexity of the visual.

9.2 DirectQuery Mode

In DirectQuery mode, Power BI sends supported queries to the underlying data source rather than importing all data into the model.

Performance can depend on database execution, network latency, source workload, query translation, and the number of source queries needed for the visual.

When a DirectQuery visual is slow, consider the following:

• Examine the underlying database query where possible.
• Check whether the source database has appropriate indexes.
• Review joins, filters, aggregations, and source table design.
• Reduce unnecessary columns and visual complexity.
• Evaluate whether aggregations or a different storage-mode strategy are suitable.

9.3 Composite Models

Composite models combine different storage modes. A visual may interact with imported data, DirectQuery sources, or a combination of model components.

In these models, investigate the actual query pathway and source activity rather than assuming every delay comes from the same storage engine.

10. Advanced Analysis: Copying and Investigating DAX Queries

Performance Analyzer can help you capture the query associated with a visual, where query details are available. Copying the query allows deeper investigation with compatible tools.

10.1 Steps to Analyze a Query

1. Open Performance Analyzer.
2. Record a refresh or interaction that reproduces the delay.
3. Expand the slow visual's performance entry.
4. Use Copy query when the action is available.
5. Open an appropriate DAX query-analysis tool, such as DAX Studio.
6. Connect to the relevant model or analysis environment.
7. Run and inspect the query under comparable conditions.
8. Use additional diagnostics where needed to examine storage-engine and formula-engine activity.

10.2 What to Investigate in the Query

• Whether the query returns a large number of rows or groups.
• Which measures are evaluated by the query.
• Whether filters or grouping columns create excessive work.
• Whether the query plan reveals expensive operations.
• Whether the model's relationships and storage design are suitable.

Important: Performance Analyzer is primarily a report-level diagnostic tool. It does not replace a complete DAX query profiler, source database profiler, or model analysis tool.

11. Measuring Performance Before and After Optimization

Optimization should be supported by repeatable measurements. A report that appears faster once may simply have benefited from caching or different system conditions.

11.1 Recommended Testing Procedure

1. Record the initial performance of the relevant report page.
2. Write down the slowest visuals and their timing categories.
3. Make one meaningful optimization at a time.
4. Repeat the same refresh or user interaction.
5. Compare the timing results.
6. Verify that the report still returns correct values.
7. Repeat the test if results vary substantially.

11.2 Example of Before-and-After Measurements

The following values are illustrative and show how to calculate improvement.

11.3 Calculating Percentage Improvement

The percentage improvement in duration can be calculated using the following formula:

Percentage Improvement =
((Before Duration - After Duration) / Before Duration) * 100

For the illustrative matrix example:

Before Duration = 2.6 seconds
After Duration = 1.4 seconds

Improvement =
((2.6 - 1.4) / 2.6) * 100

Improvement = 46.15%

The measured duration has decreased by approximately 46.15%. This does not necessarily mean that every report interaction will improve by the same percentage.

12. Common Mistakes When Using Performance Analyzer

13. Best Practices for Identifying Slow Visuals

• Begin with the report page or interaction users identify as slow.
• Record performance before making changes.
• Compare visual durations under consistent conditions.
• Inspect timing categories rather than relying on total time alone.
• Prioritize the largest bottlenecks with the greatest user impact.
• Keep DAX measures understandable and validate their logic.
• Use an efficient data model and appropriate relationships.
• Reduce unnecessary detail in large tables and matrices.
• Investigate source queries when working with DirectQuery.
• Use DAX Studio or other specialized tools when deeper diagnostics are required.
• Retest after every significant change.
• Document the original problem, optimization, and measured result.

14. Practical Exercises

Exercise 1: Identify the Slowest Visual

Objective: Use Performance Analyzer to compare the update duration of report visuals.

1. Open an existing Power BI report with at least four visuals.
2. Open Performance Analyzer.
3. Start recording and refresh the visuals.
4. Compare the recorded durations.
5. Identify the slowest visual and note its main timing category.
6. Write a short explanation of the likely bottleneck.

Exercise 2: Investigate a Slow Matrix

Objective: Determine whether a detailed matrix is slow because of query execution or rendering.

1. Choose a matrix containing multiple grouping columns and measures.
2. Record its performance.
3. Inspect its DAX Query and Visual Display durations.
4. Remove an unnecessary column or reduce the displayed detail.
5. Record the performance again.
6. Compare the results and confirm that the displayed values remain correct.

Exercise 3: Optimize a Slicer Interaction

Objective: Identify which visuals contribute most to a slow slicer interaction.

1. Select a report page with multiple slicer-connected visuals.
2. Start recording.
3. Change a slicer selection.
4. Inspect the recorded visual operations.
5. Identify the visuals with the longest durations.
6. Review their measures and interactions.
7. Repeat the interaction after making an appropriate optimization.

15. Mini Project: Power BI Report Performance Audit

Project Goal: Conduct a performance audit of a sales report and recommend improvements based on measured evidence.

Project Requirements

• A report page containing cards, charts, a matrix, and slicers.
• A baseline Performance Analyzer recording.
• A list of the three slowest visual operations.
• An explanation of the main timing category for each slow operation.
• At least two optimization changes.
• A second recording after optimization.
• A before-and-after comparison of the results.
• Validation that report calculations remain accurate.

Expected Deliverable

Prepare a short report containing the problem description, baseline measurements, identified bottlenecks, optimization steps, final measurements, and recommendations for future maintenance.

16. Interview Questions and Answers

Q1. What is Performance Analyzer in Power BI?

Answer: Performance Analyzer is a Power BI Desktop feature that records the time associated with report visual updates. It helps developers identify slow visuals and investigate the operations contributing to their performance.

Q2. Why is Performance Analyzer used?

Answer: It is used to diagnose slow report loading, delayed visual updates, and expensive interactions so that developers can prioritize performance improvements.

Q3. What is DAX Query time?

Answer: It is the time reported for executing the DAX query associated with a visual. High values may indicate expensive calculations, complex filters, or inefficient query patterns.

Q4. What does Visual Display time indicate?

Answer: It represents the time associated with rendering the visual in the report interface. Large tables, many data points, and complex formatting may contribute to higher rendering time.

Q5. What is DirectQuery time?

Answer: For applicable DirectQuery operations, this category reports time associated with querying the underlying source. Source performance, network latency, and query complexity may affect it.

Q6. How do you identify the slowest visual?

Answer: Start recording, refresh the visuals or reproduce the slow interaction, compare the recorded durations, and expand the relevant entries to inspect their timing categories.

Q7. Can Performance Analyzer help optimize DAX?

Answer: Yes. It can identify visuals with expensive DAX query execution and provide query details where available. Additional tools may be needed to analyze the query plan and engine behavior.

Q8. Does a slow visual always mean the DAX measure is inefficient?

Answer: No. The delay may be caused by rendering, DirectQuery source performance, additional processing, or multiple bottlenecks.

Q9. How can you improve a slow matrix?

Answer: Reduce unnecessary columns and rows, simplify complex measures where appropriate, review the data model, and use drill-down or filtering to display detail on demand.

Q10. How do you validate an optimization?

Answer: Repeat the same performance test under comparable conditions, compare the timing results, and verify that calculations, filters, and report behavior remain correct.

Q11. Why should you test performance more than once?

Answer: Caching, source workload, and other environmental factors can change timings. Repeated measurements help determine whether an improvement is consistent.

Q12. What is the difference between Performance Analyzer and DAX Studio?

Answer: Performance Analyzer focuses on report-level visual timing and helps identify expensive visual operations. DAX Studio provides deeper DAX query diagnostics and analysis capabilities for supported model connections.

17. Quick Revision Checklist

• Performance Analyzer is available in Power BI Desktop.
• Start recording before refreshing visuals or reproducing an interaction.
• Compare recorded visual durations.
• Inspect DAX Query, DirectQuery where applicable, Visual Display, and Other.
• Identify the primary bottleneck before making changes.
• Use query-analysis tools for deeper investigation when necessary.
• Optimize measures, model design, visual complexity, or source queries as appropriate.
• Repeat the same test after optimization.
• Verify that the report still produces correct results.

18. Conclusion

Performance Analyzer is an essential diagnostic feature for improving Power BI report performance. It helps developers determine which visuals take the longest to update and understand whether the delay is associated with query execution, DirectQuery activity, rendering, or additional processing.

The most effective workflow is to measure first, identify the main bottleneck, apply a targeted optimization, and measure again. By combining Performance Analyzer with good DAX practices, an efficient data model, appropriate visual design, and deeper query diagnostics when required, developers can create reports that are more responsive, reliable, and easier to use.

To learn more about Power BI and practical business intelligence skills, visit Microsoft Power BI Training at JustAcademy or register for a course demo.