Power BI performance tuning: how to make slow reports fast

To make a slow Power BI report fast, measure before you change anything. Performance Analyzer times every visual and shows whether the delay is the DAX query, the source or the visual. Most slowness then traces back to the model: too many columns, no star schema, auto date/time tables. Fix the model, then the DAX, then the page design.

That order matters because the fixes compound. A lean model makes every measure cheaper, and lean measures make every visual quicker. Buying a bigger capacity first, or rebuilding pages by eye, tends to cost more and fix less. This guide walks through the diagnosis and the fixes in the order we would apply them on a real Power BI report, with every behaviour checked against Microsoft Learn as of October 2026.

Where does Power BI actually spend the time?

Microsoft's optimisation guide for Power BI splits a solution into layers: the data source, the data model (the semantic model), the visualisations, and the environment, meaning capacity, gateways and network. A slow report is slow in one or more of those layers, and each needs a different fix.

For a typical small-business report built in Import mode, the time goes in two places. When the report opens or a slicer changes, each visual sends a DAX query to the model and then draws the result. When the data refreshes overnight, Power Query pulls from the sources and the model compresses and stores the data. Users feel the first; the second shows up as refreshes that run long or time out. This guide is mostly about the first, with the model fixes helping both.

How do you find what is making a report slow?

Use Performance Analyzer. Microsoft's Performance Analyzer documentation (updated July 2026) describes the steps:

1. In Power BI Desktop, open the Optimize ribbon and select Performance Analyzer. You can also open it in the Power BI service while editing a report, from the View menu.
2. Select Start recording, then Refresh visuals to time everything on the current page. Interact with the slicers your users complain about; each interaction is logged separately.
3. Expand the slowest visual. Its time is split into categories.

The categories tell you where to look:

Category	What it measures	Usually means
DAX query	Time from the visual sending its query to the model returning results	Model design or the measure itself
Direct query	Time for the external source to answer (DirectQuery tables only)	The source database, its indexes, or a complex Power Query step
Visual display	Time to draw the visual, including web images and geocoding	Too much data in one visual, or a heavy custom visual
Other	Preparing queries, waiting for other visuals, background work	Too many visuals on the page queuing behind each other

One detail is worth knowing before you read the numbers. Microsoft notes that most canvas and visual operations run on a single user-interface thread, and the reported durations include time spent queued behind other operations. A large "Other" figure spread across many visuals is a sign that the page has too much on it, not that each visual is slow.

For a visual with a slow DAX query, select Copy query and paste it into DAX query view, or use Run in DAX query view in Desktop. You can then test a rewritten measure against the exact query the visual sends. Export the results to a JSON file before and after each change, so you have evidence rather than an impression.

How do you make the data model smaller and faster?

Start here, because the model sits underneath every query. Microsoft's guide to data reduction for Import models says the VertiPaq storage engine can achieve around 10x compression, but still recommends loading as little data as possible. Smaller models refresh faster, and smaller tables lead to faster calculations. It also notes that shared capacity, which is where Pro workspaces live, hosts models up to 1 GB.

The changes that pay back most, roughly in order of effort:

• Remove columns nobody uses. Every column costs memory, and high-cardinality text columns (order references, free-text notes, timestamps to the second) cost the most. Microsoft's advice is to design with exactly the columns your known reports need, because adding a column later is easier than removing one. The same habit appears in our Power Query beginner's guide: remove columns in Power Query, before the model.
• Load less history. Do not import ten years of transactions if the reports look at three. A Power Query filter driven by a parameter, relative to the refresh date, keeps the window rolling.
• Turn off auto date/time. Microsoft's auto date/time guidance explains that every date column with the option on gets its own hidden table, which increases model size and extends refresh time. Build one date table, mark it as the date table, and switch the global option off so new files start clean. Our DAX time intelligence guide shows the date table the time functions need anyway.
• Use a star schema. One wide flat table, or a web of tables joined every which way, makes the engine work harder for every filter. A fact table surrounded by small dimension tables is the shape Power BI is built for; our star schema guide shows how to get there from a single export, and why bi-directional relationships should be the exception.
• Prefer Power Query columns to calculated columns. Microsoft says calculated columns defined in DAX typically compress less efficiently than columns added in Power Query, and are built after every table loads, which extends refresh. Use DAX columns only when the logic genuinely needs DAX.
• Summarise where detail is not needed. Loading sales grouped by day, customer and product instead of one row per order line can shrink a fact table dramatically. The trade-off is that you lose the detail, so agree with the report owners first.

A practical check: save the .pbix before and after. If the file barely shrinks after removing columns, the weight is somewhere else, usually in a high-cardinality column you have not spotted yet.

Which DAX patterns slow reports down?

Once the model is lean, look at the measures behind the slowest visuals. The common culprits are a short list, and our beginner DAX mistakes guide covers each with the fix: FILTER over a whole table inside CALCULATE where a simple column filter would do, the same expression evaluated twice instead of once in a variable, IFERROR wrappers, and measures forced to return zero instead of BLANK, which makes tables and matrices render every empty combination of rows.

Two habits make DAX tuning faster. First, change one measure at a time and re-run the copied query in DAX query view, so you know which change helped. Second, check the result as well as the speed: a measure that is twice as fast and returns the wrong total is not an improvement. If you are new to measures and filter context, what is DAX is the place to start.

How should a report page be designed for speed?

Microsoft's report guidance comes down to three rules, all in the optimisation guide linked above.

Show less data per visual. The more data a visual has to display, the slower it loads. Microsoft's example is a table left unfiltered over a very large model when users only want a few dozen rows; its fix is a Top N filter set well above what anyone needs, so the experience is unchanged and memory use drops. Tables and matrices are the most expensive visuals, so ask whether each one needs every row it shows.

Put fewer visuals on each page. Microsoft recommends limiting each page to the visuals that are necessary, and using drillthrough pages and report page tooltips for detail. It gives no number. Our working rule is to question any page with more than about a dozen visuals, and to replace rows of separate card visuals with one multi-row card, which Microsoft also suggests in its DirectQuery guidance.

Test custom visuals. Microsoft warns that a poorly optimised custom visual can slow the whole report. If Performance Analyzer shows one visual dominating "Visual display", try a built-in alternative.

What changes when a report uses DirectQuery?

DirectQuery tables hold no data; each visual and interaction sends a query to the source. Microsoft's DirectQuery model guidance is blunt that the best results often come from optimising the source database: indexes that match how reports filter and group, materialised calculations, and a date table in the source. Not every team can change the source, which is why DirectQuery is rarely a speed fix for a small business.

On the report side, the same guidance recommends the Query reduction options in Power BI Desktop's settings: an Apply button on slicers and filters, so a user building up a multi-select sends one query instead of ten, and turning off cross-highlighting where it is not needed. Switching off unneeded totals on tables and matrices also avoids extra source queries. If a DirectQuery model is still too slow, a composite model with an imported, summarised aggregation table is the next step.

Is it the capacity rather than the report?

Sometimes, but check last. A slow measure or an oversized model is slow on any capacity, and a larger capacity is a monthly cost that never goes away. The environment section of Microsoft's optimisation guide covers what does belong at this layer: capacity settings, sizing the on-premises data gateway when data lives on your own servers, and keeping data sources, gateways and capacity in the same region to limit network latency.

If you have tuned the model, the DAX and the pages and the report is still slow at busy times, the capacity question becomes real. Our Power BI licensing guide explains what Pro, Premium Per User and Fabric capacities include, the Fabric pricing guide has the current UK capacity prices, and the pricing estimator works out the monthly cost for your user count.

A tuning checklist in order

1. Record the slow page in Performance Analyzer and export the baseline.
2. Fix the model: unused columns, history window, auto date/time off, star schema, Power Query columns over DAX columns.
3. Fix the measures behind the slowest visuals, one at a time, checking results as well as speed.
4. Fix the page: Top N on big tables, fewer visuals, built-in visuals where a custom one is slow.
5. For DirectQuery: query reduction options, source indexes, then aggregations.
6. Re-record and compare with the baseline. Only then look at capacity.

If a report has been tuned this far and is still slow, or the model has grown beyond what one person can untangle, that is the point where outside help earns its fee. See how we approach Power BI consultancy and our wider data services.

Frequently asked questions

What is the quickest way to find out why a Power BI report is slow?

Open the report in Power BI Desktop, go to the Optimize ribbon and start Performance Analyzer, then select Refresh visuals. It times every visual on the page and splits each into DAX query, DirectQuery, visual display and other. The biggest number tells you which layer to fix first.

Does turning off auto date/time make Power BI faster?

It makes the model smaller and refresh quicker. Microsoft documents that every date column with auto date/time on gets its own hidden table, which increases model size and extends refresh time. Replace it with one proper date table marked as such, then switch the global option off for new files.

Will switching from Import to DirectQuery make my report faster?

Usually not. DirectQuery sends a query to the source for every visual and interaction, so speed depends on that database. Microsoft says the best DirectQuery results often need optimisation at the source itself. Use it when data is too big or too fresh for Import, not as a speed fix.

How many visuals should a Power BI report page have?

Microsoft gives no fixed number. It recommends limiting each page to the visuals that are necessary, and using drillthrough pages and report page tooltips for detail. Our working rule is to question any page with more than about a dozen visuals, and to merge separate cards into one.

Will a bigger Fabric capacity fix a slow Power BI report?

Only if the capacity is genuinely overloaded. A slow measure or an oversized model is slow on any capacity, and you pay for the larger one every month. Measure the report with Performance Analyzer first; buy capacity only when the model and DAX are already lean.

---

Easy Insight is a UK consultancy for AI, web, apps and data — senior specialists only, no juniors.