Centralize WebSocket Connections to Stop React UI Freezes

by

Summary

The system experienced a massive performance degradation and UI thread starvation as the number of synchronized real-time charts increased from one to ten. The original architecture implemented a decentralized WebSocket pattern, where each individual React component instantiated its own dedicated WebSocket connection and managed its own data subscription logic. While this worked for a single chart, scaling this approach caused an exponential increase in network overhead, redundant JSON parsing, and excessive CPU usage due to multiple concurrent event loops competing for the main thread.

Root Cause

The failure stems from a violation of the Single Source of Truth principle regarding data ingestion. Specifically:

  • Connection Proliferation: Each chart component created a new WebSocket instance, leading to $N$ active connections for $N$ charts.
  • Redundant Deserialization: Every single WebSocket connection was performing JSON.parse() on the same incoming data packets, wasting significant CPU cycles.
  • Data Scattering: The logic for filtering relevant data was embedded within the component’s useEffect hook, making it impossible to coordinate data distribution efficiently across the application.
  • React Lifecycle Coupling: The network connection was tightly coupled to the component mounting lifecycle, making it difficult to share a persistent data stream across different parts of the UI tree.

Why This Happens in Real Systems

In modern web development, this is a classic case of scaling a prototype into a production system without re-architecting for high throughput.

  • The “It Works on My Machine” Trap: Developers often test features in isolation. A single chart behaving perfectly in a sandbox environment masks the architectural flaws that only emerge when the system is integrated into a complex dashboard.
  • Component-Centric Thinking: React encourages thinking in components. While this is great for UI, applying “component-centric” thinking to data ingestion leads to fragmented, unmanageable side effects.
  • Overhead Ignorance: The cost of a single JSON.parse() is negligible, but the cumulative cost of $N$ parsers running on the same high-frequency data stream can easily exceed the frame budget of the browser.

Real-World Impact

  • Main Thread Blockage: The high frequency of onmessage events across multiple connections prevents the browser from handling user interactions, leading to “frozen” UI.
  • Increased Latency: As the CPU struggles with redundant parsing and filtering, the “real-time” data becomes increasingly delayed, losing its temporal accuracy.
  • Memory Leaks and Pressure: Managing multiple socket buffers and large JSON objects simultaneously increases the heap size and triggers frequent, heavy Garbage Collection (GC) cycles.
  • Network Inefficiency: Redundant TCP/TLS handshakes and duplicate data transfers consume unnecessary bandwidth.

Example or Code

To solve this, we must decouple the Data Provider from the Data Consumer using a centralized manager (Singleton or Context Provider) and a high-performance distribution pattern.

// 1. The Centralized Data Orchestrator
class DataStreamManager {
  private static instance: DataStreamManager;
  private socket: WebSocket | null = null;
  private subscribers: Set void> = new Set();

  private constructor() {}

  public static getInstance(): DataStreamManager {
    if (!DataStreamManager.instance) {
      DataStreamManager.instance = new DataStreamManager();
    }
    return DataStreamManager.instance;
  }

  public connect(url: string) {
    this.socket = new WebSocket(url);
    this.socket.onmessage = (event) => {
      // Parse ONCE for the entire application
      const data = JSON.parse(event.data);
      this.notify(data);
    };
  }

  public subscribe(callback: (data: any) => void) {
    this.subscribers.add(callback);
    return () => this.subscribers.delete(callback);
  }

  private notify(data: any) {
    for (const callback of this.subscribers) {
      callback(data);
    }
  }
}

// 2. The Optimized React Component
export function OptimizedChart({ chartId, lc }: { chartId: string, lc: any }) {
  const id = useId();

  useEffect(() => {
    const container = document.getElementById(id) as HTMLDivElement;
    if (!container || !lc) return;

    const chart = lc.ChartXY({ container });
    const lineSeries = chart.addLineSeries({
      schema: { x: { pattern: "progressive" }, y: { pattern: null } },
    }).setMaxSampleCount(100_000);

    const manager = DataStreamManager.getInstance();

    // Subscribe to the single source of truth
    const unsubscribe = manager.subscribe((data) => {
      // Efficiently filter data for this specific chart
      if (data.chartId === chartId) {
        lineSeries.appendJSON(data);
      }
    });

    return () => {
      chart.dispose();
      unsubscribe();
    };
  }, [chartId, lc]);

  return 
;
}

How Senior Engineers Fix It

  • Architectural Decoupling: They separate the Transport Layer (WebSockets) from the State/Data Layer and the View Layer (React/LightningChart).
  • Single Ingestion Point: They ensure that expensive operations—like network I/O and JSON deserialization—happen exactly once per data packet.
  • Pub/Sub Pattern: They implement an efficient Observer or Pub/Sub pattern to broadcast parsed data to interested listeners.
  • Offloading Work: For even higher performance, they would move the WebSocket and JSON.parse logic into a Web Worker to completely vacate the main thread for rendering.
  • Batching: They look for opportunities to batch updates (e.g., using requestAnimationFrame) so the UI only updates as fast as the screen can refresh, regardless of how fast the data arrives.

Why Juniors Miss It

  • Focus on Local Scope: Juniors focus on making the “current component” work. They view the component as an isolated island rather than part of a complex ecosystem.
  • Ignoring Complexity Scaling: They assume that if $1$ works, $10$ will work, failing to account for the non-linear growth of resource consumption in distributed systems.
  • Library Over-Reliance: They often treat libraries like React as the “engine” of the application rather than a “view layer,” leading to heavy logic being placed inside hooks where it doesn’t belong.
  • Opaque Performance Costs: They often perceive JSON.parse or new WebSocket() as “cheap” operations, not realizing the cumulative impact of high-frequency execution.

Leave a Comment