If your dashboards have so many panels that lazy loading is important, you need to reconsider your dashboard design. Endlessly scrolling to find the panel you're interested in makes for a painful user experience, and it makes it harder to compare series across panels.

I aim to keep dashboards no larger than what can be displayed in a single window on a desktop, with perhaps some supplementary plots below, often in a collapsed row. I make heavy use of "drill-down" links, preferably from tables or single-stats (or more often the "status panel" for denser displays [1]), or in panel notes otherwise, to dive further into the data.

When designing a dashboard, I ask myself "what story is this dashboard going to tell?", and as with a good novel I try to keep from straying too far from that narrative, branching side-plots out into new dashboards as needed.

[1] https://grafana.com/plugins/vonage-status-panel

It depends on what your use case for the dashboard is. If the dashboard is meant for constant display, then yes, too many panels is a bad user experience. On the other hand, if you're trying to create a "Oh my god something is wrong in production right now, show me everything so I can see at a glance" dashboard, I would rather scroll than jump between 3 tabs because of "aesthetics".

Aesthetics? How about ergonomics? In the same vein as "alert fatigue," having too many panels on a dashboard (or too many lines on a graph, etc) can overload the user, and obscure the real issues.

> show me everything so I can see at a glance

Yes, exactly, at a glance, not after scrolling through five pages. With careful dashboard design, you should be able to see a problem area actually "at a glance," and then drill-down to pinpoint the actual cause, faster than you'll find it scrolling through a single large dashboard.

I admit this is something of an ideal to aim for, and it can take a lot of time and effort to achieve, which may not be available. However, it will pay off in the "Oh my god something is wrong in production right now" scenario if you can take that time.

Agree, designing a good dashboard is a skill just like anything else it comes with experience.

It's not about aesthetics it's about identification of problems in O(log n) instead of O(n) time.

Scrolling through 100 graphs is slower than scanning 10 main graphs and 10 subgraphs per.

Same here, we just deployed a test instance running the upgraded code. No issues in our existing dashboards so far, and our initial testers are liking the speed improvements a lot.