The browser WebSocket API performs no automatic reconnection and gives scripts no way to send a protocol-level ping. What must an application-level reconnect-and-heartbeat layer get right for a browser WebSocket client?

## What the platform actually gives you Very little, and that is the point of the question. A `WebSocket` object is single-use: the ready state only moves forward and `CLOSED` is terminal, so "reconnect" always means constructing a new object and rewiring its handlers. The browser will not do this for you, will not tell you *why* a connection failed beyond a close code, and will not queue anything you tried to send while disconnected. Everything else described here is code you write. ## Deciding whether to reconnect at all The `close` event is the whole input. Three cases need separating. **You closed it.** Set a flag immediately before calling `close(1000, …)` — during a logout, a route change, or component teardown — and check it in the close handler. Without that flag the layer cheerfully reconnects a socket the application deliberately shut down, which is the most common bug in hand-rolled reconnect code. **The server closed it permanently.** Refusing a connection is useless for signalling *why*, because a rejected connection surfaces as an opaque abnormal close. So the server accepts, then closes cleanly with a code your protocol reserves — say 4001 for a bad token, 4003 for a suspended account. Those must map to "stop and surface an error to the user", not to backoff. **Everything else.** Retry. ```js socket.addEventListener('close', (event) => { if (intentional) return; if (PERMANENT_CODES.has(event.code)) { surfaceFatal(event); return; } scheduleReconnect(); }); ``` ## Backoff, jitter, and the reset trap Delays must grow — 250 ms, 500 ms, 1 s, up to a ceiling of perhaps 30 seconds — and every delay must carry randomness. Jitter is not a nicety: after a server restart, thousands of clients all disconnect within the same second, and a deterministic backoff brings them all back in the same instant, re-creating the overload that dropped them. Randomising each delay across a range spreads the return. The subtle part is *when to reset the counter*. Resetting on the `open` event looks right and is wrong: a server that accepts connections and immediately closes them — because it is overloaded, or the token is stale — turns the backoff into a hot reconnect loop at full speed. Reset only after the socket has stayed open for some minimum period, or after the first successful application message. ## Reacting to the environment instead of only to the clock Waiting out a thirty-second backoff when connectivity returned five seconds ago is a poor experience. The window fires `online` and `offline` events, and `navigator.onLine` reports the browser's current belief. Treat both as hints — `online` can be true behind a captive portal — but use `online` as a trigger to attempt a reconnect immediately, collapsing the remaining delay. Conversely, when the browser reports offline there is little value in burning attempts. Background tabs matter too. Browsers heavily throttle timers in hidden tabs, so a `setInterval` heartbeat scheduled every fifteen seconds may fire roughly once a minute once the tab is backgrounded. A dead-connection detector tuned for fifteen-second intervals will then produce false positives, or notice failures far too late. Take the tab's visibility into account: relax the detector while hidden, and revalidate the connection when the page becomes visible again. ## Heartbeats, and why they are yours to build The WebSocket API exposes no method for sending a control ping and no event for a pong; the browser handles peer pings itself, invisibly to script. So a heartbeat is an ordinary application message — `{"type":"ping"}` or a single byte — sent on an interval, with the server replying in kind. The purpose is to detect a **half-open connection**: an intermediary such as a NAT device, proxy or load balancer silently discards a connection it considers idle, and neither endpoint receives any notification. The browser still reports `readyState === WebSocket.OPEN` and fires no `close` event, possibly for a very long time. The only way to notice is to expect traffic and act on its absence: arm a timer when you send the heartbeat, cancel it whenever *any* message arrives, and if it fires, call `close()` yourself so the normal reconnect path runs. Choose an interval comfortably below the shortest idle timeout in your path — many proxies default to around a minute — and remember that the heartbeat also keeps that path warm. ## Teardown is where reconnect layers leak Each reconnect creates a new socket, and every listener and timer attached to the old one must go. The classic failure is stacking: a drop schedules a reconnect, a second event schedules another, and each generation doubles the number of live sockets until the page is opening dozens per second — a self-inflicted connection storm that looks, from the server, exactly like an attack. Guard with a single pending-reconnect handle, refuse to connect while one attempt is in flight, and clear heartbeat and detector timers in the close handler. Wiring listeners with an `AbortController` and passing `{ signal }` to `addEventListener` lets you remove all of them in one call. ## Resuming state, not just the connection A new socket is a blank slate. Subscriptions do not survive it, and messages the server produced while you were away were not held anywhere. So the layer must, on every `open`: re-send its subscriptions, and ask for what it missed — typically by sending the last sequence number or timestamp it processed and letting the server reply with a delta or a full snapshot. Consumers must also tolerate duplicates, since a message may have been delivered just before the drop and replayed after it. Designing that resume path is the difference between a reconnect layer that restores the connection and one that restores the application.