Blazor Server单用户DOM内存占用及高频事件实用性咨询

Great questions about Blazor Server's runtime behavior—let's break them down clearly:

First, a quick clarification: Blazor Server doesn’t store the actual browser DOM in server memory—it holds a RenderTree, a lightweight snapshot of your component hierarchy and their current state, used to compute updates for the browser.

For a medium-sized page (think a dashboard with a data table, form components, and navigation elements), you can expect server-side memory per user to land between 50KB and 200KB. This is just a ballpark, though—several factors shift this:

• Component count & complexity: More components (especially custom ones with lots of bound state) will increase usage. 100 simple components take less memory than 20 complex ones holding large data collections.
• State size: Components with large bound datasets (like a list of 1000 items) add more overhead, even if only a portion is rendered.
• Static content: Pages with lots of static text/HTML have smaller footprints, since Blazor optimizes static RenderTree nodes.

Simpler pages (basic forms, static content) might use as little as 20-50KB, while complex pages (rich data grids with interactive filters) could exceed 200KB.

Short answer: Directly binding onmousemove or similar high-frequency events to Blazor Server methods is generally not practical—here’s why:
Every event trigger sends a SignalR message to the server, where Blazor processes the event, updates state, computes RenderTree diffs, and sends an update back. Mouse movement fires hundreds of times per second, creating massive network chatter, spiking server load, and causing noticeable UI lag.

That said, you can work around this if you need mouse movement functionality:

• Handle events in JavaScript first: Use JS interop to process mousemove directly in the browser. Only notify the server when you need to update server-side state (e.g., when the user stops moving the mouse, or the cursor crosses a specific element).
• Add throttling/debouncing: If you must handle events server-side, implement throttling (limit events to fire once every X milliseconds) or debouncing (wait until events stop for X milliseconds before processing). This drastically cuts SignalR traffic.
• Use client-side rendering for specific features: If the tool relies heavily on high-frequency input, use Blazor WebAssembly for that component (via a hybrid approach) to keep processing local to the browser.

For example, in a drag-and-drop feature, handle real-time position updates in JS, and only notify the server when the drag starts and ends to save the final state.

内容的提问来源于stack exchange，提问作者mz1378