Do not render the wire format
A frontend should not blindly mirror every incoming event. Normalize updates, discard stale values, and produce a view model that reflects what a person can actually perceive.
For a busy dashboard, the right question is not how to render more events. It is which changes deserve a frame, which can be summarized, and which belong in history rather than the live view.
Make pressure visible
Batching, throttling, virtualization, and deferred work are useful, but they should follow a clear freshness policy. A user should understand whether a value is live, delayed, or aggregated.
Performance is part of the interaction contract. A screen that technically receives every update but stops accepting input is not real time from the user's perspective.
Shape data before rendering
The browser should not receive a firehose simply because the backend has one. A read model can send the current state, a compact change history, and an explicit freshness value. The client can then update only the rows or markers that changed.
flowchart LR
A[High-frequency events] --> B[Server aggregation]
B --> C[Current-state snapshot]
B --> D[Important event stream]
C --> E[Virtualized UI]
D --> E
E --> F[User interaction remains responsive]
Scheduling work
I separate urgent interaction from background refresh. Typing, dragging, and opening a menu should not wait behind a large list update. A refresh can be batched or deferred, while the visible control responds immediately.
function useVisibleTelemetry(events: TelemetryEvent[]) {
const visible = useDeferredValue(events);
return visible.reduce((state, event) => {
if (event.sequence > (state[event.assetId]?.sequence ?? -1)) state[event.assetId] = event;
return state;
}, {} as Record<string, TelemetryEvent>);
}
Virtualization limits DOM work, but it does not fix an oversized payload or an expensive selector. Measure all three layers: bytes over the network, work during render, and input delay while updates arrive.
Product freshness
Every live surface should have a freshness policy. A trading-like view may need the newest event; an operations summary may be more useful when it is stable for a few seconds. Showing the policy makes a small delay feel intentional rather than broken.