In a single-page app that opens an EventSource when a dashboard route mounts, users report that after moving between routes for a while the page stops loading anything and new requests sit pending forever. How would you diagnose this, and what is the fix?

## Reading the symptom "Nothing loads and requests are pending" has a small number of causes, and the network waterfall separates them quickly. If each request shows a long **Queueing/Stalled** phase before any bytes move, while the server responds fast to the same URL from curl or another origin, the browser is not sending the request at all — it is waiting for a connection slot. That is a client-side resource problem, and long-lived responses are the usual culprit. The confirming observation is a count. Filter the Network panel to the stream endpoint, leave the panel recording while you navigate between routes, and watch pending stream requests accumulate one per visit. Six-ish of them and the origin is wedged. ## Why the streams accumulate An `EventSource` is a live object holding a live connection. It is not stopped by: - the component that created it unmounting; - the reference going out of scope — an object with an open connection and pending callbacks is reachable, so garbage collection will not save you; - removing your message listeners — that stops your handlers from running, not the transport; - navigating to another route in a single-page app, because there is no document unload. It is stopped by exactly one thing: `es.close()`. And because it also reconnects itself after any drop, a leaked stream is not even a passively idle socket — it actively re-establishes itself, which is why the problem does not heal after a network blip. ## Why six leaks are enough Over HTTP/1.1 a browser holds only around six concurrent TCP connections per origin. A normal page never notices, because ordinary requests finish and release their slot within milliseconds. A server-sent events stream is the opposite kind of request: it is deliberately never finished. Every leaked stream permanently occupies one of the small number of slots, and once they are all occupied, every subsequent request to that origin — API calls, images, the next chunk of JavaScript — sits queued. Two things make it worse in the field than in development. Multiple tabs share the per-origin budget, so a user with the dashboard open in three tabs burns three slots even with zero leaks. And the failure is *partial*: requests to a different origin (a CDN, a third-party API) still work, so the page looks half-alive, which sends people hunting in the wrong place. ## The fixes, in order **1. Guarantee teardown.** Every code path that constructs an `EventSource` must return or register the matching `close()`, and the cleanup must be tied to the lifecycle mechanism your framework already provides rather than to an ad-hoc callback. Write the subscription as a function that hands back an unsubscribe: ```js function subscribeOrders(onOrder) { const es = new EventSource('/api/orders'); es.addEventListener('order', (e) => onOrder(JSON.parse(e.data))); return () => es.close(); } ``` If the constructor and the `close()` are not visible in the same few lines, the leak will come back. **2. One stream, not one per consumer.** Several widgets on a dashboard each wanting live data should not mean several connections. Open one stream in a module-level singleton or a store, fan the messages out to subscribers in memory, and reference-count so the connection closes when the last consumer leaves. **3. Reduce the number of tabs holding a stream.** Because `EventSource` is available inside workers, one shared worker can hold a single stream and distribute messages to every tab; a simpler variant elects one tab as the stream owner and rebroadcasts to the others through `BroadcastChannel`. Shared-worker availability has historically been uneven across browsers, so the elected-owner approach is easier to ship. **4. Close when nobody is looking.** Listening for `visibilitychange` and closing a hidden tab's stream — reopening on return, with a snapshot refetch — removes most of the multi-tab pressure at the cost of a reconnect. **5. Serve the endpoint over HTTP/2 or HTTP/3.** There the per-origin cap is replaced by concurrent streams on one connection, typically around a hundred, so the ceiling stops being six. Treat this as raising the ceiling, not as the fix: leaked streams still consume server-side resources — a connection, memory, and often a database subscription or a message-broker consumer per client — and a leak that is invisible in the browser is still a capacity problem on the server. ## The check that keeps it fixed Add an assertion to the app's development build, or a smoke test, that navigating away leaves no pending stream request. Connection exhaustion is slow to appear and easy to reintroduce, and it never reproduces on the developer's machine, where nobody visits the same route forty times.