A slow Power BI report is usually caused by one of a handful of things: too many visuals on one page, a table visual trying to show every row, a DAX measure that does far more work than it needs to, a model that's bigger than it should be, or a DirectQuery source that's slow to answer. Don't guess. Open Performance Analyzer in Power BI Desktop, refresh the page, and it will tell you which visual is slow and whether the time is going to the query, the drawing, or waiting. Then fix that one thing first.

Step 1: find the slow visual

Power BI Desktop has a free tool built in for this.

  1. Open the report in Power BI Desktop.
  2. On the Optimize ribbon, select Performance Analyzer.
  3. In the pane that opens, select Start recording.
  4. Select Refresh visuals.

Each visual on the page gets a line with its total time, broken into parts:

  • DAX query: how long the model took to answer the visual's query. If this is the big number, the problem is the measure or the model.
  • Direct query: how long the source database took, for tables in DirectQuery mode. If this is the big number, the problem is the source or the query it's being sent.
  • Visual display: how long the visual took to draw. If this is the big number, the visual is showing too much, or it's a custom visual that's slow.
  • Other: time spent waiting, often behind other visuals on the same page. A high "Other" on many visuals usually means the page simply has too many of them.

Sort by total time and start at the top. You can copy the query of a slow visual and paste it into DAX Studio to test changes quickly.

The usual culprits, and what to do about each

Too many visuals on one page

Every visual runs its own query. A page with 25 visuals is 25 queries, and they queue behind each other. Microsoft's guidance is to keep each page to what's needed and move detail somewhere else.

Fix it by splitting the page, moving detail to a drillthrough page, or using a report page tooltip so the detail only loads when someone hovers. Cards that each show one number are a common offender: replace six cards with one multi-row card or a small table.

A table visual showing everything

A table or matrix with no filter tries to pull every row. On a large table that's slow to query and slow to draw. Microsoft's own example is a table left showing 100 million rows by default.

Add a Top N filter, a default slicer selection, or a filter on the visual so it shows the rows people actually look at. Nobody scrolls through 100,000 rows.

A heavy DAX measure

If the DAX query time is high on one visual, look at the measures in it. Common patterns that make measures slow:

  • FILTER over an entire table when a simple column filter would do.
  • Iterators (SUMX, AVERAGEX and similar) over large tables, especially when they call other complex measures for every row.
  • Measures that return a value for every row even when there's nothing to show, which forces Power BI to calculate combinations nobody asked for.

Rewrite the slowest measure first and test it again in Performance Analyzer. Small changes can make a big difference.

A bloated model

A bigger model is a slower model. Unused columns, columns with millions of unique values, DAX calculated columns and auto date/time all make every query do more work. Our post on memory limit exceeded errors walks through how to shrink a model; the same steps make reports faster.

Also check the relationships. Bidirectional relationships and many-to-many relationships make filters travel further than they need to. Use single-direction relationships in a star shape (fact tables in the middle, lookup tables around them) unless you have a clear reason not to.

A slow DirectQuery source

If the Direct query time is high, the database is the bottleneck. You can tune the database, but often the better answer is to import the data instead, or to import most tables and keep only one in DirectQuery. We cover that decision in DirectQuery vs Import.

Custom visuals

Some custom visuals from AppSource are well built and some aren't. If a custom visual has a high Visual display time, try the closest built-in visual and compare. Microsoft's advice is to test every custom visual before you rely on it.

The environment

If the report is fast in Desktop and slow in the Power BI service, look at where things live. A gateway on an underpowered machine, or a database in a different region from your Power BI tenant, adds delay to every query. On Premium Per User or a capacity, check whether other workloads are competing for the same resources.

What not to do first

Don't start by buying a bigger license. A Premium capacity won't fix a page with 30 visuals or a measure that loops over a whole fact table. Find the slow visual, fix the cause, and only then decide whether you need more capacity.

When to call someone

You can often fix a slow page yourself in an afternoon with Performance Analyzer. It's worth bringing in help when the slow part is a measure you didn't write and can't follow, when the report is only slow in the service, when the model needs to be restructured rather than tweaked, or when a report the whole company opens every morning has become unusable.

For one slow report, our $299 Power BI fix gets a senior consultant on it, and you don't pay if we can't fix it. If the whole reporting setup needs rework, see Power BI advisory. And if the report is slow because its gateway keeps dropping, see why your Power BI gateway keeps disconnecting.

Sources: Microsoft Learn, Use Performance Analyzer, Optimization guide for Power BI, Data reduction techniques for Import modeling.