React WebSocket Performance: Buffer, Don't Render Every Msg

Stop Feeding WebSocket Streams Directly to React State

Hot WebSocket streams are a common source of UI jank: you wire every incoming message to setState, and the app re-renders hundreds of times per second. That work is real — diffing, commit, layout — and the UI (inputs, animations, scroll) pays for it. The right 2026 best-practice for React WebSocket performance is simple: decouple the hot stream from the render path. Buffer messages, coalesce them on a display tick, and expose a subscription bridge (useSyncExternalStore or an RAF-based flush). Let React see only coalesced updates.

The problem: render storms

A small example you’ve likely seen:

// naive — runs on every message
ws.onmessage = (event) => {
  const msg = JSON.parse(event.data);
  setMessages(prev => [msg, ...prev]);
};

That’s fine at 1–2 messages/sec. At 100–200 messages/sec it becomes 100–200 re-renders/sec. The result: dropped frames, input lag, and engineers blaming React rather than the event fanout.

React batches updates, but not across independent asynchronous callback invocations arriving at arbitrary times. The fix is to prevent those callbacks from scheduling renders directly.

The approach: buffer, coalesce, and subscribe

There are three concepts to adopt:

• Buffer incoming frames in a mutable structure that React doesn’t observe (module scope or ref).
• Flush the buffer on a controlled cadence: requestAnimationFrame (preferred for display-aligned updates) or a scheduler.
• Expose a subscription surface to components (useSyncExternalStore is the React-correct primitive). If you use TanStack Query for server state, feed the coalesced updates into its cache (setQueryData or invalidation) so the cache remains authoritative.

Why RAF?

requestAnimationFrame aligns flushes to the display refresh rate (60Hz, 120Hz, etc.) and pauses in background tabs. That means many messages that arrive inside a single frame collapse into one update. Using RAF keeps the render count bounded by the display and prevents render storms.

Concrete example

Below is a compact external store that buffers messages at module scope and flushes them once per animation frame. Components subscribe via useSyncExternalStore.

// messageStore.js (module scope)
const buffer = [];
let subscribers = new Set();
let frameScheduled = false;
let snapshot = [];

export function pushMessage(msg) {
  buffer.push(msg);
  scheduleFlush();
}

function scheduleFlush() {
  if (frameScheduled) return;
  frameScheduled = true;
  requestAnimationFrame(() => {
    frameScheduled = false;
    if (buffer.length === 0) return;
    // coalesce buffer into a single snapshot update
    snapshot = [...buffer, ...snapshot].slice(0, 1000); // cap size
    buffer.length = 0;
    subscribers.forEach(s => s());
  });
}

export function subscribe(cb) {
  subscribers.add(cb);
  return () => subscribers.delete(cb);
}

export function getSnapshot() {
  return snapshot;
}

And a React hook to consume it:

import { useSyncExternalStore } from 'react';
import { subscribe, getSnapshot } from './messageStore';

export function useMessages() {
  return useSyncExternalStore(subscribe, getSnapshot);
}

Finally, the socket wiring pushes into the store without ever calling setState directly.

// socket.js
import { pushMessage } from './messageStore';
const ws = new WebSocket('wss://example/stream');
ws.onmessage = e => pushMessage(JSON.parse(e.data));

Now every frame React receives at most one notification and every interested component reads the same coalesced snapshot. React WebSocket performance improves because you’ve turned an unbounded render rate into a bounded, display-aligned cadence.

Integrating with TanStack Query

If TanStack Query (React Query) is your server-state layer, treat the socket as a courier, not a parallel store. Two patterns:

• Invalidate: when a message means "something changed", call queryClient.invalidateQueries(key). This is simple and server-authoritative.

• setQueryData: when the message carries full or safely mergeable data (chat messages, a price tick for a visible symbol), call queryClient.setQueryData(key, old => merge(old, payload)). This avoids an extra round-trip and is essential for high-frequency streams.

Example:

// on coalesced flush
const updates = getSnapshot();
updates.forEach(u => queryClient.setQueryData(['order', u.id], old => ({ ...old, ...u })));

Start with invalidation when correctness matters and switch to setQueryData when performance demands it.

Lifecycle and backpressure

This approach buys you responsiveness at the cost of a small infrastructure layer. Important operational considerations:

• Lifecycle: open/close the socket in a long-lived owner (module scope, top-level provider) — not inside components that mount/unmount frequently. Use StrictMode-safe cleanup.
• Reconnect: implement exponential backoff with jitter, refresh tokens before reconnects if needed, and resync (invalidate or refetch) on reconnect to catch missed messages.
• Backpressure: cap buffers or drop old messages deliberately when overwhelmed. Log overflow and expose metrics (message rate, buffered depth) so you can detect pathological cases.

Trade-offs and when to bypass React entirely

Trade-offs: you add a small layer and a lifecycle surface to manage, but you dramatically reduce CPU churn and make renders deterministic. For non-UI-critical or low-frequency streams, the extra complexity may not be worth it.

For extreme cases (single value updating >60Hz, e.g., live price ticker), consider writing directly to the DOM via refs or drawing to canvas. That bypasses React entirely for that leaf and avoids reconciliation cost.

Practical checklist

• Don’t call setState directly from fast onmessage handlers.
• Buffer messages outside React, flush on RAF or a scheduler.
• Expose updates via useSyncExternalStore for concurrency-safe subscriptions.
• Integrate with TanStack Query via invalidateQueries or setQueryData depending on trust and frequency.
• Implement reconnect/backoff and resync workflows.
• Cap buffers and monitor message/backpressure metrics.

Conclusion

React WebSocket performance is mostly an architectural problem. The simplest, most effective fix is to keep the hot stream outside React’s render path, coalesce updates to a display-friendly cadence, and feed the cache or components with the coalesced snapshot. This pattern preserves responsiveness and plays well with modern tools like useSyncExternalStore and TanStack Query — a small trade for far more predictable UI behavior.

How are you handling high-frequency WebSocket streams in your apps — RAF coalescing, external stores, server batching, or something else?