Optimizing Real-Time Dashboards: How We Achieved a 40% Performance Boost

The Problem: Cascading Re-renders

Our initial implementation used a single top-level WebSocket listener that dispatched updates to a global Redux store. Every incoming message — even for a single metric — triggered a full re-render of the dashboard tree. At 50ms update frequency, this meant 20 renders per second across hundreds of chart components.

The fix was surgical: we decomposed the global store into per-metric atoms using Zustand, so each chart component subscribed only to its own data slice. A chart that wasn't receiving new data simply didn't re-render. This alone cut our render count by 65%.

D3 + React: The Integration Problem

D3 and React both want to own the DOM. Our first approach — letting D3 mutate SVG elements directly inside a React component — caused React's reconciler to fight D3 on every update cycle. The result was visual tearing and dropped frames.

We adopted a hybrid pattern: React owns the component lifecycle and layout, while D3 is used purely as a math library (scales, axes, path generators). The SVG elements are rendered via React JSX, with D3 computing the coordinates. This eliminated the DOM contention entirely and made the charts fully controllable via React state.

WebSocket Backpressure

At peak load, the server was emitting updates faster than the browser could process them. We implemented a client-side frame budget: incoming messages are queued, and the render loop processes only the latest snapshot per metric per animation frame (via requestAnimationFrame). Older intermediate values are discarded — the dashboard always shows the most recent state without processing every intermediate update.

Results