Home / Blog / Performance
Performance

How to fix a slow Power BI report

By Philip van den Berge, PL-300Updated July 20269 min read

A slow report is almost always fixable, and it is rarely the fault of the visuals themselves. Nine times out of ten the problem is the data model or the DAX underneath. Here are the eight most common culprits, in the order I usually check them, and how to fix each.

Before changing anything, measure. Open Performance Analyzer (View → Performance Analyzer), record a page refresh, and see which visuals are slow and whether the time is going to the DAX query or the visual itself. For deeper work, DAX Studio and the VertiPaq Analyzer tell you exactly which tables and columns are bloating your model. Fix what the data tells you, not what you assume.

01Too many visuals on one page

Every visual fires its own query. A page with 25 visuals fires 25 queries on every interaction. Aim for a handful of well-chosen visuals per page and split busy pages in two. Fewer, clearer visuals are faster and easier to read.

02A flat table instead of a star schema

The single biggest performance (and correctness) issue I see is one giant flat table, or a tangle of relationships with bidirectional filters. Restructure into a star schema: narrow fact tables surrounded by small dimension tables, single-direction relationships. Power BI's engine is built for this shape and rewards it heavily.

03Heavy or misused DAX

Calculated columns that should be measures, FILTER wrapped around entire tables, and iterators over millions of rows all slow things down. Use measures instead of calculated columns where you can, filter columns rather than whole tables, and lean on variables (VAR) to avoid recomputing the same thing repeatedly.

04Importing columns you never use

Every column you import costs memory and slows refresh, even if no visual uses it. In Power Query, remove columns you do not need, filter rows at the source, and only bring in what the report actually shows. A leaner model is a faster model.

05DirectQuery when Import would do

DirectQuery sends a live query to the source for every interaction, which is slow unless you genuinely need real-time data. Unless you have a specific reason, use Import mode with a scheduled refresh. It is dramatically faster because the data lives in Power BI's in-memory engine.

06Transformations done in the wrong place

Cleaning and shaping should happen as far upstream as possible: in the source, then Power Query, and only then DAX. Calculated columns doing work that belongs in Power Query bloat the model. Push logic upstream and the whole report gets lighter.

07High-cardinality columns and Auto Date/Time

Columns with millions of unique values (full timestamps, free-text IDs) are expensive to compress. Split timestamps into date and time, drop unnecessary precision, and turn off Auto Date/Time (it silently creates a hidden date table for every date column). Use one proper date dimension instead.

08Too much granularity, no aggregation

If your report only ever shows monthly totals, it does not need every individual transaction loaded at full detail. Pre-aggregate where you can, or use aggregation tables so summary visuals hit a small table and only drill-downs touch the detail.

The 80/20: if you only do two things, fix the data model (star schema) and remove unused columns. Those two alone resolve most "my report is slow" cases I get handed.

Still slow?

Sometimes the report is fine and the bottleneck is a gateway, a slow source, or a capacity limit. If you have worked through this list and it is still crawling, the model likely needs a proper audit rather than another tweak, which is exactly the kind of thing a fresh expert pair of eyes fixes quickly.

Dashboard audit & fix

Report crawling? Send it over.

Send me your .pbix and I'll tell you exactly what's slowing it down and what it takes to fix it, with a fixed quote. No calls needed.

Get a fix quote →