When a Power BI report is slow, the cause is usually one of four things, and in my experience they rank in this order: the shape of the data model, pages trying to do too much at once, DirectQuery used where import would do, and, last and least often, badly written DAX.
That ranking matters because it's the reverse of where people look. The instinct is to blame the formulas or the software. The truth is that most slow reports are slow by design: the foundations were laid in a shape that can't be fast, and everything built on top inherits it.
Here's how to tell which one you've got, without needing to read a line of code.
Which cause do your symptoms point to?
No honest percentages exist for this, so what follows isn't a statistic, it's a diagnostic table built from the patterns I see over and over. Find your symptom in the left column.
| Symptom | Most likely cause | Fixing it honestly takes |
|---|---|---|
| Every page is slow, everywhere, for everyone | Model shape: flat tables, no proper structure | The big one: remodelling, days of work |
| One page crawls, the rest are fine | That page has too many visuals | Small: redesign one page, hours |
| Slow on first open, fine once it's warmed up | Large model loading, or capacity waking up | Varies: trim the model, or a capacity question |
| Every slicer click hangs for seconds | DirectQuery against a source that can't keep up | Medium: switch to import where possible |
| One visual is slow, everything else instant | One inefficient measure (the DAX, at last) | Small: rewrite one measure, often under an hour |
| Fast in Desktop, slow in the browser | Capacity, gateway or DirectQuery in the path | Medium: needs proper diagnosis first |
| The report is fast but the numbers are stale | Not performance at all: your refresh is failing | Small to fix, but it needs monitoring |
Two of those rows deserve flags. The last one isn't a speed problem, it's a trust problem wearing a speed costume, and it's the more dangerous of the two because stale numbers look exactly like fresh ones. And the first row is the expensive one, so it gets its own section.
Is it the model? (Start here)
The single most common reason reports are slow is that the data was loaded the way it came out of the source system: a handful of enormous, wide tables, every column kept "just in case", calculated columns bolted on over the years. Power BI will accept that shape without complaint. It just gets slower with every month of data and every new visual, because the engine is built to be fast at one particular shape, narrow tables of facts joined to small tables of descriptions, and punishes everything else.
The tell is symptom one in the table: everything is slow, everywhere, and it's been getting gradually worse. No single visual is guilty. The foundations are.
The uncomfortable part for a buyer is that this can't be patched. Rewriting measures on a badly shaped model is rearranging furniture in a house with subsidence. The fix is remodelling, it's days of work rather than hours, and the honest framing is that you're not paying to make a report faster, you're paying to rebuild the layer every current and future report stands on. Done properly it also fixes problems you hadn't attributed to the model, like reports that disagree with each other.
Is the page doing too much?
Every visual on a page sends its own queries when the page opens, and again when someone clicks a slicer. Thirty visuals means thirty-plus queries racing each other, every interaction. Pages accumulate visuals the way hallways accumulate coats: one at a time, each reasonable, until the page takes eleven seconds to respond and nobody can say why.
The tell is that one busy page crawls while the rest of the report is fine. The fix is cheap and slightly political: the page is answering four different people's questions at once, and it should be two or three pages with a clear job each. This is a design problem before it's a technical one, and the fastest fix on this list.
Is DirectQuery the problem?
Power BI has two fundamental modes. Import copies your data into the model, where the engine is extremely fast. DirectQuery leaves the data where it lives and translates every click into a live query against your source database, which means every interaction is only as fast as that database on that day.
DirectQuery exists for good reasons: data too large to copy, or a genuine need for up-to-the-minute figures. But it's often chosen for a bad one, the vague feeling that "live" must be better. Ask yourself what actually changes if the sales figures are as of 7 a.m. rather than this second. For most management reporting the honest answer is nothing, and import mode, refreshed on a schedule, is both faster and kinder to your source systems.
The tell is slicer clicks that hang for seconds while the source database thinks. If your report runs on a capacity and the bill is part of the pain, that's a related but separate conversation: why your Fabric capacity bill is so high covers it.
Is it the DAX?
Sometimes, and it's telling that this comes last. Genuinely inefficient measures exist, and one bad one can drag a visual from instant to painful. The tell is precise: one visual is slow while its neighbours on the same page are instant. That's usually one measure doing something expensive, and a specialist can typically find and rewrite it quickly. It's the cheapest fix on the list when it really is the cause.
But DAX gets blamed far more often than it's guilty, for a human reason: it's the visible code, so it's where people point. Slow DAX on a well-shaped model is rare. Fine-looking DAX that performs horribly on a badly shaped model is everyday, and the second case is a model problem. Blame the formulas last.
What does diagnosing and fixing this actually cost?
Three honest routes, depending on the size of the problem.
If it's one stubborn visual or one page, and someone technical on your side wants to work it live, a £100 unblocking session is built for exactly that: screen share, find it, fix it, written note of what changed.
If the whole estate feels slow and you don't know why, guessing is the expensive option. The £950 Health Check scores performance and refresh as one of its six areas, 48 checks in all, and comes back within five working days with the causes named and ranked. Knowing whether you're facing an hour of DAX or a fortnight of remodelling is worth a great deal before you commission either.
If the diagnosis is the model, that's a rebuild conversation, sized to your estate. It's the most expensive answer, which is exactly why it's worth being certain before you buy it.
Common questions
Why does my Power BI report take so long to load?
The likeliest causes, in order: a data model shaped poorly for the engine, too many visuals firing queries on one page, DirectQuery waiting on a slow source database, or a large model loading on first open. Badly written DAX is the least common cause, despite being the most commonly blamed. The pattern of the slowness tells you which: everything slow points at the model, one page points at design, one visual points at a measure.
How fast should a Power BI report be?
Opening a page and clicking a slicer should feel like seconds, not a coffee break. There's no official number, but in practice people stop noticing speed at a second or two and stop using reports well before ten. If your team has developed the habit of clicking and then checking their phone, the report has already failed the only test that matters.
How many visuals should a Power BI page have?
Fewer than most pages have. Every visual runs its own queries at every interaction, so a 30-visual page is running a small stampede on every click. Beyond performance, a page that dense usually means nobody decided what question it answers. Somewhere under ten visuals, with a clear job for the page, is where both speed and comprehension live.
Is DirectQuery slower than import?
Almost always, yes. Import copies data into Power BI's own engine, which is built for exactly that and is extremely fast. DirectQuery sends every interaction to your source database and inherits its speed, its load and its bad days. Use DirectQuery when data volume or genuine real-time need forces it; default to import otherwise.
Will buying more capacity make my reports faster?
Occasionally, but it's the most expensive guess available, and if the model is the problem you'll pay every month to run bad foundations faster. Diagnose before you upgrade: if one page or one visual is slow, capacity was never the issue. Spending on capacity to outrun a modelling problem is how bills grow while reports stay slow.
Can a slow report be fixed without rebuilding it?
Often, yes. Overloaded pages, DirectQuery misuse and inefficient measures can all be fixed within the existing report, usually in hours or days. The exception is the model itself: if the foundations are the problem, patches buy months rather than years, and the honest fix is remodelling. A proper diagnosis first tells you which side of that line you're on.
Why is my report fast in Power BI Desktop but slow online?
Because the browser version has more in the path: the Service, a capacity with other workloads on it, possibly a gateway back to your data, and DirectQuery round trips if you're using it. Desktop on your machine has none of that. The gap between the two is itself diagnostic information, and it usually points at capacity, gateway or connection mode rather than the report file.
Prices for my own services are as published on the linked pages, September 2026. If the report that's slow is also the report the board reads, the free 20-minute intro call is the quickest way to work out which of the four causes you're most likely looking at.