Why Your Power BI Report Is Slow, and How to Fix It

A slow Power BI report is almost always caused by the data model and DAX, not the hardware running it: too many columns, a missing star schema, high-cardinality fields, or inefficient measures force Power BI's engines to do more work than necessary. Open Performance Analyzer first to see whether the delay is in DAX, visual rendering, or refresh, then fix the specific bottleneck it points to instead of guessing.

How Power BI performance works

Power BI relies on two internal engines. The storage engine retrieves compressed data from the model and is fast when the model is well designed. The formula engine evaluates DAX, applying filters, aggregations, and the logic inside your measures. Most performance problems come from one of two places: the formula engine doing excessive calculation, or the storage engine scanning more data than it needs to because of poor modeling. Report speed depends more on model design than on hardware or internet connection.

The 7 most common reasons Power BI reports are slow

1. Poor data model design

The data model is the single biggest performance factor. Common problems: importing flat tables instead of a dimensional model, duplicated data across tables, columns that are never used, and relationship chains more complex than the business question requires. Power BI performs best on a star schema, where fact tables connect directly to dimension tables. Our data modeling best practices guide and star schema vs. snowflake schema guide cover the model shape to build toward.

2. High-cardinality columns

Cardinality is the number of unique values in a column. High-cardinality columns, such as transaction IDs, timestamps down to the second, GUIDs, or long text fields, increase memory use and slow filtering. Removing or bucketing unnecessary high-cardinality columns is often the fastest single fix available.

3. Inefficient DAX measures

A measure that returns the right number is not always a measure that returns it efficiently. Row by row iteration over a large table, repeating a calculation inside one measure, and deeply nested CALCULATE calls all force the formula engine to do more work than it needs to.

This margin measure calculates the same subtraction twice, once for the test and once for the result:

Margin % Unoptimized =
IF (
    [Total Sales] - [Total Cost] > 0,
    DIVIDE ( [Total Sales] - [Total Cost], [Total Sales] )
)

Rewriting it with variables calculates each value once and returns the same result:

Margin % =
VAR SalesAmount = [Total Sales]
VAR Margin = SalesAmount - [Total Cost]
RETURN
    IF ( Margin > 0, DIVIDE ( Margin, SalesAmount ) )

VAR also means each intermediate result is calculated once and reused wherever it is referenced, instead of being recalculated every time. See our guide to DAX variables and DAX performance optimization guide for more rewrites like this one.

4. Broken or missing query folding

Query folding lets Power BI push transformations back to the data source instead of processing them locally. When folding breaks, often after adding a custom column or an unsupported Power Query step, transformations run inside Power BI instead, and refresh times and visual load times both increase.

5. Too many visuals on one page

Each visual sends its own query. A page with many visuals can trigger dozens of queries at once, especially when a slicer changes. As a rule of thumb, keeping a page to somewhere around 6 to 10 visuals tends to keep it responsive, though the real number depends on your model and how complex each visual is. If removing visuals from a page improves load time immediately, the page had too many, not a modeling problem.

6. The wrong storage mode

Power BI supports Import, DirectQuery, and composite models. DirectQuery can introduce latency because every interaction queries the external source directly, so if the source system is slow, the report is too. See our Import vs. DirectQuery guide for how to choose between them.

7. Large datasets without optimization

A large dataset is not the problem by itself; an unoptimized one is. Watch for slow slicer responses, long initial load times, and memory pressure during refresh. Scaling Power BI takes deliberate optimization, not just importing more rows.

Data source and refresh issues

Report speed is not only about the model. A slow source database, an overloaded warehouse, or an unindexed query can add delay before Power BI even starts rendering. Long refresh times against enterprise sources are often a gateway constraint or an inefficient incremental refresh setup rather than a Power BI problem at all.

A step-by-step troubleshooting framework

1. Identify what is actually slow. Data refresh, page load, visual interaction, and slicer filtering point to different causes, so narrow it down before changing anything.

2. Run Performance Analyzer. In Power BI Desktop, go to View > Performance Analyzer, start recording, then refresh the visuals. It reports DAX query duration, visual display time, and other overhead separately, which tells you whether the problem is calculation or rendering.

3. Check model size. In Model view, look for unused columns, unnecessary tables, large text fields, and duplicated data. Removing them is often an instant win.

4. Review the DAX measures Performance Analyzer flagged as slow, following the rewrite pattern above: replace row-by-row FILTER iteration with variables and built-in functions where you can.

5. Validate relationships. Many-to-many relationships, unnecessary bidirectional filtering, and ambiguous filter paths all cost performance; our relationships and cardinality guide covers how to simplify them.

6. Test visual complexity by temporarily removing visuals from the page. If performance improves immediately, the page had too many visuals rather than a modeling problem.

When optimization is not enough

Sometimes the fix is not a small tweak. Consider restructuring the semantic model if the PBIX file is near practical memory limits, the report relies heavily on DirectQuery against a slow source, relationships have become genuinely complex, or performance problems persist after working through the steps above. Restructuring usually beats another round of incremental fixes at that point.

Getting help

A structured performance review, following the framework above, finds the real bottleneck faster than trial and error. If your reports are still slow after working through this guide, that is a sign the fix is architectural rather than incremental. Contact CaseWhen if you want a second set of eyes on a specific model.

FAQs

Why is my Power BI report slow after publishing?

A report that felt fine in Desktop can slow down in the service because of capacity limits, DirectQuery latency against the live source, or more people interacting with it at once than you tested with locally.

How many visuals should a Power BI page contain?

There is no fixed number. As a rule of thumb, 6 to 10 visuals per page tends to stay responsive, but a page of simple card visuals can hold more, and a page of complex custom visuals may need fewer than 6.

Does DAX affect performance?

Yes. A measure that iterates row by row over a large table, or repeats the same calculation several times inside itself, forces the formula engine to do avoidable work. Using variables and built-in time intelligence functions instead of manual FILTER logic is usually the fastest fix.

Is Import mode faster than DirectQuery?

In most cases, yes, because Import reads from data already cached in memory rather than querying the source on every interaction. See our Import vs. DirectQuery guide for the full comparison.

Sources

• Performance Analyzer in Power BI Desktop - Microsoft Learn