Node.js Socket.IO Server ↔ Official JavaScript Client: Is Concurrent-Load Latency a Transport or Adapter Decision?

A Socket.IO 4.x server on Node.js, paired with the official JavaScript client, must be sized for a workload where latency is expected to surface only when concurrent connections and emits ramp up. The open decision is where such latency would belong: the Engine.IO polling-to-WebSocket upgrade path, the single process's event loop, or the multi-node adapter layer.

Two documented behaviors frame it. Socket.IO starts with HTTP long-polling and upgrades to WebSocket unless configured otherwise; forcing websocket-only removes upgrade overhead but changes proxy, firewall, and fallback behavior. With polling enabled, one session's polling requests must reach the node holding that session, so sticky sessions enter the picture. Scaling out with the Redis adapter adds serialization and pub-sub hops and does not make emits globally ordered.

Constraints: knobs such as maxHttpBufferSize, permessage-deflate, and acknowledgement timeouts are version-sensitive, so any comparison needs a pinned version matrix, with client runtime, proxy, and adapter layers separated before attributing anything to the protocol.

Open questions:

• Should the baseline concurrency comparison run websocket-only or polling-with-upgrade first, to isolate upgrade-storm effects from steady-state handling?
• Does keeping the polling fallback make sticky sessions a tail-latency requirement rather than only a correctness one?
• When emit-to-ack latency grows only under concurrent load, which layer should be instrumented first: server event-loop delay or adapter pub-sub hops?