IE10 WebSocket: single‑threaded implementation causes latency under concurrent connections

Question

Goal
Evaluate the impact of IE10’s documented WebSocket limits on real‑time applications that open many sockets to the same host.
Constraints and Uncertainty
IE10 enforces a hard limit of six WebSocket connections per domain and processes all socket traffic on the main UI thread. When more than six sockets are opened, latency spikes are observed, especially under heavy JavaScript execution. The Microsoft documentation does not indicate whether future updates will raise the connection limit or adopt a multi‑threaded approach.
Unresolved Decision
It remains unclear whether the 6‑connection cap or the single‑threaded design will be altered in subsequent IE10 patches or Windows updates, and how that would affect latency behavior.
Questions

Will future IE10 updates increase the WebSocket connection limit or switch to a multi‑threaded implementation?
What mitigation strategies can developers employ to reduce latency when exceeding the six‑connection threshold?
How can we reliably measure the impact of the UI thread’s CPU usage on WebSocket latency in IE10?

Tasadduq Burney · Answer

Answer
No future IE10 updates will raise the WebSocket connection limit or introduce a multi‑threaded implementation; the limit of six concurrent sockets per hostname and UI‑thread‑bound processing are fixed.
Confirmed facts

IE10 (and IE11) enforce a hard limit of six WebSocket connections per hostname, baked into wininet.dll.
All WebSocket frame callbacks run on the main UI thread; heavy JavaScript blocks them, increasing latency.
Microsoft ended all IE10 updates in January 2020; no further patches exist.

Likely explanation for observed latency
When more than six sockets are opened, the extra connections stay in CONNECTING until a slot frees, and any active socket’s onmessage/onopen handlers are delayed by whatever UI‑thread work is running, causing the spikes you see.
Steps to mitigate latency in IE10

Shard the domain: open sockets to different sub‑domains (e.g., ws1.example.com, ws2.example.com) to gain additional 6‑connection pools.
Multiplex logical channels over a single WebSocket (e.g., assign message IDs and demultiplex in JS).
Offload CPU‑intensive work to Web Workers and postMessage results back to the UI thread that owns the sockets.
For read‑heavy paths, fall back to Server‑Sent Events or long‑polling, which are not subject to the same UI‑thread WebSocket callback bottleneck.

Measuring UI‑thread impact
Use the F12 Profiler:

Record the “Network” tab while sending ping frames; note the round‑trip time of each WebSocket frame.
Enable the “UI Responsiveness” timeline to see when the main thread is busy.
Inject performance.now() timestamps in onmessage handlers and compare them to a Web Worker heartbeat that posts a message every 10 ms.
Run a controllable busy loop (e.g., while (performance.now() < start + duration) {}) on the main thread and observe latency growth.

If you can share the measured latency numbers or confirm whether Web Workers are already in use, we can refine the recommendation further.

IE10 WebSocket: single‑threaded implementation causes latency under concurrent connections

Goal

Constraints and Uncertainty

Unresolved Decision

Questions

1 answer

Answer

Confirmed facts

Likely explanation for observed latency

Steps to mitigate latency in IE10

Measuring UI‑thread impact

Your perspective belongs here.

0 question comments