This is a question that has come up a few times over the past few months from several clients and so I figured it’d make a good quick blog post that can easily be pointed at to save time. I encourage you to make it to the end of this short post to find out why this is an interesting question.
Short-Answer: Yes, all visuals on a report generate queries against the source.
Longer-more-nuanced-Answer: No. Only the visuals that are currently visible (and filters) generate queries against the source. Furthermore, in almost all cases a single query is generated per visual.
Proof
The following Power BI file is using Live Connect to an on-premise Analysis Services tabular instance. However, the general behavior that we’ll see is the same regardless of which of the 3 storage options we chose…
- Import Mode (where data is imported directly into the Power BI file and becomes a Power BI dataset upon publishing
- Direct Query (where data is left in the source system)
- Live Connect (where data resides in an Analysis Services instance)
Clik here to view.
When we refresh this page with both visuals visible, we find 2 queries in our trace… 1 query for Reseller Sales by Product Category and another query for Internet Sales by Product Category.
Clik here to view.
Let’s see what happens when we hide one of the visuals. Below is the report with only the Internet Sales by Product Category chart visible.
Clik here to view.
And now after we refresh the report page, we see that only a single query was generated for Internet Sales by Product Category.
Clik here to view.
Why is this important?
Typically the question arises during a discussion of how to add more visuals to an existing report – perhaps one that’s already a bit on the “busy” side.
Sure, more “stuff” can always be added to an existing report page… shrink the font size, make the charts smaller… we’ve probably all been down that path before and we’ll probably do it again at some point – sometimes that truly is the correct answer.
However, this approach will often times have a negative impact on the user experience (UX). Reports with a ton of visuals can be hard to “consume” (i.e. difficult for humans to focus on what’s important) and can also be slow due to the number of concurrent queries that are generated each time the report is viewed.
As an alternative to “adding more stuff”, I like to encourage report developers to work more closely with their end users. Try and learn how they intend to actually use the report. Often times you’ll discover there are several use cases for a busy report.
A good question to lead with is: What specific task(s) are you using this report to accomplish?
To which a common response might be: I’m responsible for analyzing the out-of-stocks from the previous month. Some of the questions I need to be able to answer are: Which products were OOS the most (both in quantity and lost revenue)? Which Suppliers are associated with these products? And what are out Payment Terms with said suppliers?
In many cases, a good overall understanding of what the end user is trying to accomplish with the report will allow the report developer to create a better, more useful report. By spreading the information out across report pages (via drillthrough) and/or by leveraging buttons & bookmarks to toggle on/off the visibility of visuals in creative ways, the report developer creates a more guided and less cluttered report consumption experience. As an added bonus, the simple reduction in clutter will often times result in a more snappy interactive report consumption experience.