A practical guide to faster Power BI reporting
Power BI Performance Optimisation: Why Reports Run Slowly and What to Check
Separate slow report interactions from slow refreshes, find the bottleneck and test improvements while preserving accuracy.
At a glance
Measure the right problem
- Separate the symptomsWaiting for visuals and waiting for fresh data are different problems.
- Follow the evidenceCheck models, DAX, visuals, sources and capacity.
- Verify the outcomeCompare repeatable timings and confirm the figures still reconcile.
On this page
Power BI performance optimisation starts with a specific question: what is slow, for whom, and when? A report that takes too long to react to a filter needs a different investigation from a model whose overnight refresh misses the morning reporting deadline.
Both problems can have several causes. Changing a formula, removing charts or buying more capacity without evidence may leave the main delay untouched. Start with a repeatable symptom, identify where time is spent and make a controlled change.
01 · Identify the symptom
Slow interactions and slow refreshes need different checks
Slow report interactions are the delays users experience when opening a page, changing a slicer, drilling into detail or selecting a chart. Investigate the query behind the visual, the work needed to draw it and the environment serving it.
Slow data refreshes are delays in bringing updated data into an Import semantic model. The work can include reading sources, transforming data, loading tables and processing the model. Start with refresh history and compare duration, failures and data volumes across recent runs.
A visual refreshing on screen is not the same as a semantic model loading new data. With DirectQuery, report interactions can send queries to the underlying source, so source performance can directly affect the user’s wait. Record the actual storage mode before choosing a remedy.
For example: a procurement page may respond quickly but still show yesterday’s spend because its import failed. Conversely, a successfully refreshed model may have a slow supplier slicer. These are illustrative scenarios requiring different investigations.
02 · Establish a baseline
Measure a repeatable user journey
Choose an important task, such as opening the monthly finance page and filtering to one entity. Record the report version, page, filters, user or security role, data volume, time and environment. Include whether the delay happens in Desktop, the Power BI service or both.
Use Performance Analyzer to record the interaction and inspect timings by visual. It separates categories including DAX query, visual display and other activity. “Other” can include waiting for other visuals; it is not a diagnosis of slow DAX. Export the results for comparison.
Repeat the same sequence. Keep first-load and repeated-load observations separate because caching can change the result. A single fast run on a developer’s laptop does not establish the experience of users during a busy reporting period.
03 · Review the foundation
Check the semantic model before rewriting every measure
The semantic model is the layer of tables, relationships and calculations behind the report. Microsoft’s star-schema guidance explains how fact tables for business events and dimension tables for filtering and grouping support usable, efficient models.
Check that tables have a consistent level of detail and that relationships match the business logic. Review unnecessary relationship complexity and filter paths with the developer. A model change must preserve intended filtering and row-level security.
For Import models, inspect unused columns, unnecessary history and columns containing many distinct values. Reducing unnecessary imported data can reduce model size and refresh work. Hiding a column does not remove its stored data.
Agree the detail users need before removing anything. Summarising invoice lines may help some reporting workloads, but it can remove the ability to investigate individual transactions. Document that trade-off and check dependent reports.
04 · Investigate expensive calculations
Use timings to focus DAX work
Start with the measures used by the slow visuals. Copy the visual’s query from Performance Analyzer and investigate it under the same filters that reproduce the problem. A long formula is not automatically the slowest formula, and query time can reflect the model and source as well as the measure.
Look for repeated calculations and logic that asks for more work than the result requires. Microsoft’s guidance on DAX variables shows how storing a repeated expression can avoid recalculating it and make a measure easier to inspect. Treat this as a technique to test, not a universal speed guarantee.
Compare totals, subtotals, blank values and different filter selections after each rewrite. A faster measure that changes the agreed KPI definition is a defect, not an improvement.
05 · Reduce unnecessary work on screen
Review visuals, interactions and detail
Inspect pages with many visuals, large tables or matrices and broad default selections. Ask which information users need immediately and which belongs on a drill-through page. Check whether every visual needs to respond to every selection.
Microsoft’s Power BI optimisation guide recommends limiting unnecessary visuals, reducing the data displayed and testing custom visuals. Use the timing evidence to distinguish a slow query from a visual that takes a long time to draw.
Test a simpler presentation or narrower default view in a copy of the report. Preserve the route to necessary detail and explain any changed navigation. A cleaner page should still help people make the decision it was designed for.
06 · Follow the data path
Check sources, transformations and refresh design
When data retrieval is slow, involve the source owner. Compare the relevant query or extract at the source with the Power BI run. Check recent changes in volume, database workload, API behaviour, file organisation and gateway health where a gateway is used.
In Power Query, query folding pushes supported transformations to the source. Check whether filtering and other costly steps are handled there or in the Power Query engine. Folding depends on the connector and transformations; Excel and CSV files do not offer a database query engine to fold into.
For growing Import tables, assess incremental refresh. Refreshing an appropriate recent window can avoid repeatedly reloading all history. Verify that date filtering actually limits the data retrieved and that the policy accounts for late-arriving records and corrections to older transactions. Plan and test the initial historical load separately.
Agree an acceptable freshness window with the business. Changing the schedule can ease contention, but it must still make the required data available before users need it.
07 · Check shared resources
Investigate capacity when the pattern points to it
If several reports slow down together, especially at busy times, investigate shared resources as well as individual reports. Compare incident timestamps with refresh activity, user demand and other workloads.
Where the workspace uses a supported dedicated capacity, ask the administrator to review the Microsoft Fabric Capacity Metrics app for utilisation, expensive operations and throttling. The available evidence depends on the environment and the administrator’s access.
Also compare gateway and network conditions, particularly when the service behaves differently from Desktop. Changing capacity may be justified by measured demand, but first establish what resource is constrained and whether reducing avoidable work would address it. Record the cost and expected benefit of any proposed capacity change.
Use this in your review
Power BI performance optimisation checklist
Work through the symptoms that apply. Each row is a starting point for investigation, not proof of a particular cause.
| Symptom | Investigation | Evidence to keep |
|---|---|---|
| ☐ A page or slicer is slow | InvestigationRecord the exact interaction and compare visual timings. Identify whether query time, drawing or waiting dominates. | Evidence to keepPage, filters, user role, first/repeated-load timings and exported trace. |
| ☐ One measure-heavy visual is slow | InvestigationInspect its query, measures, model relationships and filter context. Test one focused change. | Evidence to keepOriginal query, changed logic, timing comparison and reconciled results. |
| ☐ The overnight refresh keeps growing | InvestigationCompare table volumes, transformation steps and source retrieval. Assess the refresh window and any incremental policy. | Evidence to keepRefresh history, rows retrieved, source timings and latest data timestamp. |
| ☐ DirectQuery interactions are slow | InvestigationTrace the source query with its owner; compare source workload, gateway and network conditions. | Evidence to keepInteraction time, source-query evidence and matching infrastructure timestamps. |
| ☐ Desktop is quick; the service is slow | InvestigationCompare data volume, user/security context, connections and environment rather than assuming they are identical. | Evidence to keepVersion, role, test sequence and environment differences. |
| ☐ Several reports slow down together | InvestigationCorrelate busy periods with shared capacity, refreshes, source workload and gateway activity. | Evidence to keepAffected reports, incident window and relevant administrator metrics. |
| ☐ A report became slow after a release | InvestigationCompare the changed model, measures, visuals and source steps with the last known good version. | Evidence to keepChange record, reproducible symptom and a tested recovery route. |
Keep report responsiveness and data freshness as separate acceptance measures. Improvements in one do not automatically establish improvements in the other.
08 · Prove the improvement
Compare like for like and protect correctness
Ask for a short record of the baseline, identified bottleneck, proposed change and result. Repeat representative journeys using comparable data volumes, filters, roles and load conditions. Keep first-load and repeated-load results separate, and include refresh completion and data freshness where relevant.
Make controlled changes with retained versions and a rollback route. Reconcile key figures, test security roles and check other reports sharing the model. Agree realistic acceptance criteria with users; there is no single response-time target that suits every report.
Our Power BI reporting brief guide helps define the required behaviour. Once changes are accepted, the Power BI support services guide explains how to maintain ownership, documentation and escalation.
A related Power BI client story
Understand the workflow behind the report
Denova’s global VAT-team case study describes a Power BI task-status report within a solution using Power Apps, Power Automate and SharePoint. The team mapped the existing process and adapted the workflow as testing revealed additional cases.
That wider context matters when investigating reporting: know where the data originates, how it reaches the report and which business activity users depend on. The case study illustrates connected delivery, rather than a measured report-speed improvement.
See how an embedded developer brought files, approvals and task tracking together using the client’s Microsoft tools.
Copy into your investigation
Give the investigation a useful starting point
Copy these fields into a support ticket or optimisation brief. Include enough evidence to reproduce the issue, and share sensitive examples through your approved channels.
Plan the next step