Don't ask.
Be told.

Ordinary HTTP is request-response: the client initiates, the server replies, and the exchange is over. The server has no way to speak first — it can't tap the client on the shoulder and say "something changed." That's a perfect fit for fetching a document, and a fundamental mismatch for anything that updates on the server's schedule: a message arriving, a price ticking, another user's cursor moving.

So to build "live" on top of a protocol that can't push, developers reach for a workaround — have the client ask, repeatedly, and hope to catch news soon after it happens. That's polling, and it works, sort of. But it's a simulation of real-time built out of not-real-time parts, and it pays for the illusion in latency and wasted work. Quantifying that cost is the cleanest way to see why a different primitive — a connection the server can push over — is the real answer.

Polling means the client asks "anything new?" every fixed interval. It has two costs, and both are quantifiable. The first is latency: an event can happen at any moment within the interval, so on average the client doesn't learn about it until half the interval has passed. Poll every 10 seconds and your users feel about 5 seconds of staleness on average — an eternity for a chat.

The second is waste. Most polls return nothing — you asked, there was no news — so you're making a stream of requests just to hear "no," burning bandwidth, server CPU, and battery. And the two costs are in tension: to cut the latency you shorten the interval, but that multiplies the number of empty polls. Poll every second instead of every ten and you've traded 5 seconds of lag for ten times the wasted requests. There's no setting of the dial that gives you both low latency and low waste, because you're fundamentally guessing when to ask. The fix isn't a better interval — it's not guessing at all.

A WebSocket changes the primitive. After a quick HTTP handshake that "upgrades" the connection, the client and server hold open a single, persistent, full-duplex TCP connection — either side can send a message at any time, for as long as the connection lives. Now the server doesn't wait to be asked; it pushes the instant an event occurs.

Both costs of polling vanish. Latency drops from "half a poll interval" to "one network hop" — tens of milliseconds, effectively the moment it happens. And there are no wasted requests: nothing crosses the wire until there's actually something to send. That's the whole appeal — a WebSocket turns "check constantly, usually find nothing" into "be notified precisely when it matters." The next section makes the difference exact.

Polling with interval T: an event is equally likely anywhere in the window, so the expected wait to learn of it is half the interval, and the requests that return nothing are all the polls minus the ones that caught an event:

T=10s → 5s average staleness; over 100s that's 10 polls for maybe 2 events → 8 empty requests. Shrink T and latency falls but waste climbs.

A WebSocket push arrives at roughly the one-way network latency, independent of any interval, with no empty requests — so it clears a real-time perceptual threshold that polling can't:

50 ms push clears a 500 ms "feels live" bar; a 10 s poll's 5 s average doesn't. The runnable version below computes poll latency, wasted requests, and the push comparison.

Real-time isn't free, so match the transport to the need:

The honest default is: don't reach for WebSockets unless you need them. A persistent connection costs server resources per client, complicates load balancing (a socket is stateful; a stateless request isn't), and needs reconnection and heartbeat machinery. For streaming from the server only — an LLM's tokens, a live log — SSE is lighter and often enough. Save WebSockets for genuinely interactive, bidirectional, low-latency features, where the poll math is unacceptable and the two-way channel earns its keep.

The operational reality is that a persistent connection is stateful, and state is what makes scaling hard. Each open socket pins a bit of memory and a connection slot, so a million concurrent users is a million live connections to hold; load balancers must keep a client stuck to the server that holds its socket (or you need a shared pub/sub layer to fan out messages across servers). Plan for that from the start, or your real-time feature falls over at scale. And connections drop — networks are flaky, phones sleep — so you need automatic reconnection, heartbeats/pings to detect dead connections, and a way to catch up on messages missed while disconnected.

Two more. Reaching for WebSockets when SSE or polling would do: bidirectional, low-latency is powerful but heavy, and using it for infrequent one-way updates is over-engineering. And treating socket messages as trusted: a WebSocket is an open door into your server, so authenticate the connection, authorize every message, and rate-limit — the same discipline as any endpoint. Used where it fits, a WebSocket is the difference between an app that feels alive and one that feels like it's refreshing behind your back. The rule is simple: when staleness is unacceptable and updates are frequent and two-way, stop asking — open a line and be told.