In this guide 6 sections
A slow Power BI report usually has one of five causes. Whole tables are loaded, the model is too wide, calculated columns do heavy work, a page holds too many visuals, or the source answers slowly. Time each stage before changing anything.
Find out whether it is the refresh or the page
Two different waits get called slow. People mix them up. One is the scheduled refresh that runs overnight. The other is the pause a manager feels when a page opens or a slicer is clicked. The fixes are different, so name the wait first.
Open the report in Power BI Desktop and switch on Performance Analyzer; press Start recording, refresh the visuals and read the timings. Each visual shows a DAX query time and a display time. The slowest visual is your first suspect.
For the refresh, look at the refresh history in the service. Note the duration and which tables take longest.
Check whether you are loading whole tables
Many reports pull the full sales or ledger table from the source, including ten years of rows nobody opens. Every refresh then copies all of it. That is waste. The model grows, memory fills and every query scans more data than it needs.
Ask what the report actually answers. If managers only compare the current and previous financial year, load those two years and keep the rest in an archive file. Filter at the source with a date parameter, not after loading.
Where the source is a database, check that the filter folds back to it. In Power Query, right click a step and see whether View Native Query is available. If it is greyed out, the filtering happens in Power BI after the full table has arrived.
- Row count of each table in the model
- Oldest date loaded versus oldest date used
- Whether View Native Query is available on the last step
- Incremental refresh set up on the biggest fact table
Look for a wide model and heavy columns
A fact table with eighty columns copied straight from the ERP is a common sight. Remove every column no visual, filter or relationship uses. Free text such as remarks and long address fields compress badly and cost the most memory. Drop them.
Calculated columns are stored in the model and recalculated at every refresh. A column that concatenates three fields over a million rows is cheap to remove and cheap to rebuild upstream. Move it into the query or the source view.
Measures are different. They run only when a visual asks, and that is where the DAX cost appears. A measure that loops over every row with SUMX on a large table will show up in Performance Analyzer as a long DAX query. So will one that nests several CALCULATE calls.
- Columns with text longer than fifty characters
- Date and time stored together when only the date is needed
- Two-way relationships between large tables
- Measures that call other slow measures
Count what sits on one page
Every visual sends its own query. A page with twenty cards, charts and tables fires twenty queries when it opens, and again for each slicer click. Cards that show the same figure in three places repeat the work.
Cut the page down to the figures one role needs. Move detail tables to a drill-through page that opens only on request; replace a stack of cards with one table or matrix where it reads just as well.
Slicers matter too. Watch them. A slicer on a customer name with thousands of values is slow to draw; use a dropdown, or move it to a filter pane.
Test the source before blaming the report
If the refresh is long but the model is small, the source is probably the bottleneck. Run the same query in the database tool or open the Excel file from the shared drive. A query that takes ten minutes there will take ten minutes in Power BI.
Check the hours. A refresh at nine in the morning competes with billing runs and month-end posting. Move it to the quiet window. For a live DirectQuery report, ask whether the source has an index on the date and branch columns that every filter uses.
Write down each finding with its timing. Fix one thing at a time. Re-run Performance Analyzer after every change so you know what helped.
Slow report diagnosis sheet
A worksheet of one page with five rows, one for each cause: whole tables, wide model, heavy columns, crowded page and slow source. Each row has columns for what to check, the timing found, the change made and the timing after. A header block records the report name, the wait complained about and the date tested.
Open a blank worksheet to printQuestions owners ask
Why is my Power BI report fast in Desktop but slow in the service?
The service shares capacity with other reports and users, and live connections cross a gateway. Desktop uses your own machine. Compare the model size and gateway load before assuming the report itself changed.
Does a bigger machine fix a slow report?
Sometimes it hides the problem for a few months. A model loaded with unused rows and columns will grow back into the extra memory. Trim the model first, then consider more capacity.
Should I use Import or DirectQuery?
Import is usually faster for the viewer because data sits in memory. DirectQuery suits data that must be current every minute. It leans on the source, so a slow source makes slow pages.
How do I know which visual is the slowest?
Use Performance Analyzer in Power BI Desktop. It lists each visual with its query time and render time. Sort by duration and start with the top two.