Most business reports should have between one and five pages. Beyond that you are usually building several reports that happen to share a file, which is a legitimate thing to do but should be a decision rather than an accident.
The page count is the wrong measure though. The right one is whether each page has a single job that you can state in a sentence. A twelve-page report where every page answers one clear question is well built. A three-page report where each page tries to serve four audiences at once is not, and it will be slower, harder to read and less trusted than the twelve-page one.
What does the right size look like?
| Report purpose | Sensible page count | The single job of each page |
|---|---|---|
| Executive summary or board pack | 1 to 3 | The headline, the trend, the exceptions |
| Departmental operational report | 3 to 6 | One area of the operation per page |
| Deep-dive analysis for specialists | 5 to 10 | One dimension of the problem per page |
| Self-service exploration tool | 1 to 2 plus filters | Let people slice, don't pre-build every view |
| Everything for everyone | This isn't a report | Split it by audience |
The last row is the one worth dwelling on, because it is the most common failure and it never announces itself. Reports do not get designed to be forty pages. They get designed with six, and then every new request adds one, because adding a page is easier than saying no or asking which existing page should change.
What actually goes wrong with a large report
Nobody knows where to look. A person who opens a twenty-page report to answer one question has to remember which page it is on. Most will not, and after two or three attempts they will ask a colleague instead. The report is technically complete and practically unusable.
Every page competes for maintenance. When a definition changes, twenty pages need checking rather than four. When someone adds a product category, twenty pages might break. Maintenance cost scales with surface area, and large reports quietly become expensive to own.
Performance degrades. Every visual sends its own queries. A page with thirty visuals fires thirty-plus queries every time somebody clicks a slicer. That is usually where slowness comes from, and it is covered properly in why your Power BI report is slow.
Trust spreads thin. If two of forty pages have a definition problem, people do not distrust those two pages. They distrust the report. Surface area is risk, and every page is another chance to be wrong in front of someone who matters.
The thirty-visual page
The related problem, and the more damaging one, is pages that are too dense rather than reports that are too long.
A page with thirty visuals is generally the result of a requirements process that asked what people would like to see and then built all of it. Everything on the page had a supporter, so nothing got cut. The result answers no single question well, because the eye has nowhere to land and no visual is prominent enough to be the answer.
A well-designed page usually has somewhere between three and eight visuals with a clear hierarchy: one dominant element that is the answer, a small number supporting it with context, and the detail available if someone wants it rather than shown by default. Somebody should be able to open the page, look at one place, and have what they came for in a few seconds.
The test I use: cover everything on the page except the largest element. Does what remains answer the question the page exists for? If not, the hierarchy is wrong regardless of how many visuals there are.
How do you cut a report down?
Start with what people actually use. Usage data tells you which pages get opened, and it is reliably uncomfortable, because a report's owner can usually name the two pages that matter and is often wrong about which of the rest anybody looks at.
Then apply the decision test to each page: if the numbers on this page changed, would somebody do something differently? Pages that fail that are interesting rather than useful. Interesting is not worthless, but it does not need to be in the report people use weekly.
Then split by audience rather than by topic. This is the move that resolves most oversized reports. Finance, operations and the board want the same underlying figures at different levels of detail, and trying to serve all three on one page produces something that suits none of them. Three focused reports on one shared model is nearly always better than one report with three audiences arguing over the layout.
That last point is the important one commercially: splitting reports does not mean duplicating work. The model is the expensive part and it stays shared, which is what keeps the numbers consistent across all three. Reports are windows onto it, and windows are cheap. This is also why self-service works when it is built on a shared model and fails when it is not.
When many pages is the right answer
Do not read any of this as a rule that reports must be small.
Some genuinely need to be large. A monthly operational pack covering fifteen depots may legitimately need a page per depot, and that is a well-designed report if each page has the same layout and a single job. Repetition with a consistent structure is easy to navigate, because once someone learns one page they know all fifteen.
Paginated, print-style reports follow different rules again. A statutory report or a document intended for printing is not competing for someone's attention in the way a dashboard is, and page count is driven by content.
The distinction is whether the pages are repetitions of one design or forty different designs. Forty variations is where the cost lives.
What about drill-through instead of more pages?
Often the better answer, and underused.
Rather than building a summary page and twelve detail pages people navigate by hand, build the summary and let people click through to detail filtered to whatever they clicked. The detail page is one page serving twelve purposes, because it inherits the context from where the user came from.
This keeps the report small while making the detail available, which is usually what people wanted when they asked for more pages. It also matches how people think: they see something odd in the summary and want to know more about that specific thing.
Common questions
How many pages should a Power BI report have?
One to five for most business reports, though the number matters less than whether each page has a single clear job. If a page cannot be described in one sentence, it is doing too much regardless of how many other pages exist.
How many visuals should be on one Power BI page?
Usually three to eight, with a clear visual hierarchy so the main answer dominates. Beyond about ten, performance suffers because every visual queries independently, and readability suffers because nothing stands out as the answer.
Is it better to have one big report or several small ones?
Several small reports built on one shared model, in most cases. The model is the expensive part and stays shared, so the numbers remain consistent, while each report can be focused on one audience. One large report serving three audiences tends to satisfy none of them.
Why is my Power BI report slow with many pages?
Page count itself has limited effect, since only the open page queries. Density is what matters: a single page with thirty visuals fires thirty-plus queries on every interaction. If one page crawls while others are fine, that page is doing too much.
How do I decide what to remove from a report?
Check usage data for which pages get opened, then ask of each remaining page whether a change in its numbers would cause anyone to act differently. Pages failing both tests can be retired. Expect resistance, because every page has someone who requested it.
Should each department have its own report?
Usually yes, built on the same shared model. Departments genuinely need different detail and different framing, and trying to serve them all in one report produces compromise. Sharing the model rather than the report is what keeps everyone's numbers agreeing.