Slow Performance of Collapse/Expand in Matrix Table in Paginated Report on Microsoft Fabric

[Mahmud_karimov]

I have a Matrix table designed in a Paginated Report, with the "Product Category -> GL Code" in Expand/Collapse mode. The performance is noticeably slow when the report is published to Microsoft Fabric.

• Locally, within the Designer, it runs fast.
• However, on the web, every time you click to expand or collapse, it takes around 4 seconds.
• I have checked through the profiler, and it does not appear to be firing any queries to the database upon these actions. It seems to be an issue with the web implementation itself.

This delay is very frustrating for our users, and they are now considering moving away from this product because of the poor user experience.

Is there any fix or optimization available to address this? The dataset is relatively small, with only 5-20 rows depending on the filter.

Any insights or suggestions would be greatly appreciated.

[Anonymous]

I have reduced item to 1. One category and it has one product. Its still expanding/collapsing in 4 seconds. You would think it will load faster in third expand time but no, still takes its 4 second. So this can confirm that i has nothing to do with data size. As mentioned earlier it't not firing query database. Definitely something to do with web impementation of it!

[Anonymous]

Hi, @Anonymous and @Mahmud_karimov 

Do you also encounter this performance issue in Power BI Report server? Just to confirm whether this problem only exists in Power BI fabric workspace.
Due to low capacity of Power BI Fabric workspace, region, network and other issues, you will encounter this problem when opening reports in the workspace. If the performance requirement is high, I think you need higher capacity.
Usually capacity is related to our available cpu. You mentioned that your report did not trigger data source query, which is good, so let's start from the workspace itself. Different capacity levels have different v-cores. More v-cores usually bring higher load capacity and can respond to report requests faster:

Simplifying capacity management with unified v-cores | Microsoft Power BI Blog | Microsoft Power BI

Microsoft Fabric concepts - Microsoft Fabric | Microsoft Learn

Specifically, this v-core can help us render the report content in the browser. Specifically, this v-core can help us render the report content in the browser. If your capacity also runs other reports, these v-cores will be consumed for calculation at the same time.
Paginated reports are pre-rendered, and calculations will be performed by these cores.  High performance requires higher CUs. You can learn how your CUs work to understand why a report takes about 4 seconds to render in the workspace when no data source query is triggered:

Fabric Capacities – Everything you need to know about what’s new and what’s coming | Microsoft Fabric Blog | Microsoft Fabric

Best Regards

Jianpeng Li

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[Anonymous]

Thank you rajasaadk_98 

Hi, @Mahmud_karimov 

If you want to find the cause of the slowdown, I think it is necessary to refer to the following articles, which will help you determine what caused the slowdown:
First, this article explains how to view the performance of Power BI Service and the meaning of the corresponding indicators of performance, which will help you understand the slowdown:

Diagnosing Performance of Paginated Reports in Power BI – Random Procrastination (gosbell.com)

Here is the official documentation:

View diagnostics for Power BI paginated reports - Power BI | Microsoft Learn

In the following case, uploading a paginated report to the Power BI service was extremely slow, and he used some tools to capture which requests caused the slowness:

Solved: Extremely slow paginated reports due to high conne... - Microsoft Fabric Community

The following is an overall flow chart of the slowness of the inspection report. In general, the paginated report does not generate a semantic model. Whenever data needs to be displayed, some queries are sent to the data source and then the results are presented:

Troubleshoot report performance in Power BI - Power BI | Microsoft Learn

The best practice is to use query parameters of paginated reports to filter out some unnecessary data before using it in your main dataset, which will give you a better experience:

Data retrieval guidance for paginated reports - Power BI | Microsoft Learn

Process large Power BI paginated reports - Power BI | Microsoft Learn

Paginated reports are suitable for printing. Do not add too much interaction. If interaction is required, consider using Power BI reports:

Optimization guide for Power BI - Power BI | Microsoft Learn

SSRS Best Practices for Performance and Maintenance (mssqltips.com)

Best Regards

Jianpeng Li

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[rajasaadk_98]

The delay you're experiencing with expand/collapse in the paginated report on Microsoft Fabric seems related to the web rendering of the report rather than database queries. Here are some steps to help improve performance:

1. Reduce Visual Complexity: Simplify the matrix design if possible, as complex visuals can slow down the rendering.
2. Limit Data Scope: Apply filters to limit the number of rows and categories rendered in the report.
3. Upgrade Service: Ensure your workspace is on a Premium capacity, which can offer better performance.
4. Report Caching: Enable or configure caching for the paginated report to improve response times.
5. Test in Another Browser: Some browsers handle web-based rendering better than others, so testing in a different browser might help.