Real-time updates: WebSockets, SSE, and push.
The plain web waits to be asked. Real-time updates let the server speak the moment it has something. Here is the field that makes that happen, in plain language.
By default the web is request and response: the client asks, the server answers, the conversation ends. So a screen only reflects what was true at the last request. Real-time updates are the family of techniques for getting fresh data to the client the instant it exists, instead of on the next poll. We climb the ladder one rung at a time, polling, long polling, Server-Sent Events, WebSockets, and Web Push, and link the canonical specs so you can read the source yourself.
The server cannot tap the client on the shoulder.
In the standard HTTP model the client asks and the server answers. The server cannot start the conversation on its own.
Picture a counter at a shop. The browser walks up, asks for something, the server hands it back, and the exchange ends. To find out whether anything changed, you walk up and ask again. That request-and-response shape is simple and it scales, but it has one built-in limit. RFC 6202 states it plainly: in the standard HTTP model a server cannot initiate a connection with a client nor send an unrequested response, so it cannot push asynchronous events on its own.
Real-time updates are the set of techniques that work with or around that limit, to get fresh data to the client the moment it exists. There are a few honest ways to do it, and they sit on a ladder. Each is a real, named approach with its own trade-offs, not a ranking where one always wins. The anchor idea for the whole page: the value is recency, fresh the moment it exists, not volume.
A relatable version runs through this page. Picture a sales voice co-pilot on a live call. As the rep talks, fresh things keep appearing on screen. A note the system just extracted, an account detail that finished loading, a prompt about renewal timing. None of that is useful a minute late. That is a real-time-updates problem. This page is about the field and the standards behind it, not about how any one product is wired.
- Open a connection→
- Connection established←
- Deal stage changes to Won
- Deliver the update←
Staleness has a cost that grows with how live the use case is.
For a live call, a one-minute-old screen is effectively wrong. The freshness budget is seconds or less, and polling forces a bad trade to meet it.
A minute late is a different answer.
When the use case is live, the worth of an update decays fast. A note that lands while the rep is still on the call is useful. The same note a minute later is just history. The freshness budget shrinks as the experience gets more live.
Poll rarely or flood the server.
Poll every few seconds and the screen is stale between asks. Poll constantly and you flood the server with mostly-empty requests. RFC 6202 walks through exactly this tension and the latency math behind it. Everything further up the ladder exists to beat that trade.
The limit is built into HTTP.
Because plain HTTP cannot push, every real-time technique is a deliberate way to give the server a voice. Hold a request open, keep a stream open, or open a channel both sides can use. The differences between them are the subject of the next section.
Each open channel takes a slot.
Every held request or long-lived connection consumes a slot on the server. When many sessions are live at once, the choice of technique drives how many concurrent clients one machine can carry. It is a real engineering trade-off, and the right pick depends on the traffic shape.
Climb the ladder one rung at a time.
Each rung fixes a specific shortcoming of the one below. Pick the rung that fits the job, not the one highest on the list.
| Technique | Communication shape |
|---|---|
| Polling | Repeated request and response |
| Long polling | Response waits for news |
| SSE | Server-to-client event stream |
| WebSocket | Bidirectional message channel |
| Web Push | Delivery through a push subscription |
Five honest ways to get fresh data to the client. The prism beam climbs from plain to capable, and each rung answers a plain question the rung below leaves open.
1Polling, the baseline
Ask again, and again.
The client asks on a timer, every few seconds. It is simple and it works everywhere, which is why it is the baseline. The catch is the trade in the section above. Freshness is capped by the interval, and between real updates most requests come back with nothing new. Everything else on the ladder exists to beat that trade.
Polling
- Request 1
No change.
- Request 2
No change.
- Request 3
New item returned.
Open channel
- Connect
Establish a persistent channel.
- Wait
Keep the channel available.
- Event arrives
Server sends the new item.
2Long polling and HTTP streaming
Hold the question open until there is news.
With long polling the client asks, and the server holds the request open and answers only when it actually has news. The client immediately asks again, so there is always a pending request the server can reply through. With HTTP streaming the server keeps one response open indefinitely and writes new data into it over time.
RFC 6202 documents both, along with their known issues. It notes that for long polling the gap after each response, before the next request goes out, means worst-case latency can span several network transits. That transit-count is the spec's observation about long polling in general, not a figure for any particular system. It also notes that intermediaries and buffering can interfere with streaming.
- Client asks
The request remains open while no update is available.
- Server responds
Return an event or a timeout response.
- Client asks again
Open the next waiting request.
3Server-Sent Events
One stream, server to client.
Server-Sent Events are a standardized one-way stream from server to client over a single long-lived HTTP response, defined in the WHATWG HTML Living Standard, §9.2. The browser's EventSource opens it, and the server replies with the text/event-stream media type and sends events as simple text records.
The wire shape a reader will actually meet: data: lines, concatenated across consecutive lines, an optional event type, and a last-event-ID for resuming. The spec also builds in automatic reconnection with a server-suggested retry delay, so a dropped connection is a handled case, not a failure. It is a good fit when updates flow mostly one way, server to screen, which is the common case for a live feed of fresh items.
id: 42
event: note
data: {"status":"ready"}
retry: 3000One text event stream, with reconnection behavior supported by the client.
4WebSockets
Both sides can speak at once.
WebSockets give a full-duplex channel. After an opening handshake that upgrades an HTTP connection, both sides can send messages at any time over one TCP connection, with low per-message overhead. RFC 6455 states the motivation directly: provide two-way browser-to-server communication without opening multiple HTTP connections or relying on long polling.
The spec covers the upgrade handshake, text and binary frames, and control frames including the framed close handshake, so shutting a channel down is an orderly, expected step. WebSockets are a good fit when the client and server both need to speak freely and promptly, rather than one side mostly listening.
| Direction | Example message |
|---|---|
| Client → server | Start transcription |
| Server → client | Partial transcript |
| Client → server | Stop transcription |
| Server → client | Final transcript |
5The transport underneath
What carries it shapes the math.
One honest paragraph of context. SSE and ordinary HTTP ride on whatever HTTP version is in play. RFC 9113, HTTP/2 multiplexes many independent streams over one connection, with flow control, which changes the old too-many-open-connections math that motivated some of these techniques in the first place. This is context for reading the ladder, not a recommendation. The right pick still depends on the use case and the traffic shape.
- Stream 1
- A long-lived event response.
- Stream 2
- A document request and response.
- Stream 3
- Another independent request.
Frames from different streams use the same connection.
6Web Push
Reach the person when nothing is open.
Push notifications are a different shape entirely. They deliver an event to a device or user agent even when the app or page is not open. RFC 8030 defines generic event delivery over HTTP, with a push service the client subscribes to and an application server that sends through it.
Frame it as the tool for reaching the person when nothing of theirs is currently connected, distinct from the live-channel techniques above. Application-layer encryption of the payload and a voluntary identification scheme are defined in companion RFCs 8291 and 8292, worth naming only if that depth is wanted.
- App server
Sends a message using an existing push subscription.
- Push service
Routes it through the platform’s push infrastructure.
- Device
Handles the message according to permissions and platform behavior.
A screen that reflects now.
New items appear the instant they exist, with no manual refresh and no polling lag. The rest is a menu of trade-offs, not a winner.
Once the server has a voice, the experience changes shape. A clear menu is on the table: one-way and simple with SSE, two-way and flexible with WebSockets, reach-when-closed with Web Push, or the low-effort baseline with polling. The right pick depends on the use case, and it is a menu, not a ranking.
Resilience comes built into the standards. SSE's automatic reconnection and last-event-ID, and the framed close handshake in WebSockets, mean a dropped connection is an expected, handled case rather than a failure. And headroom to scale comes from matching the technique to the traffic shape, and to the transport beneath it, which is what lets one service carry many live sessions at once.
Back to the relatable example, strictly as an illustration of the problem. On a live call, the value is that a fresh item can land on screen the instant it is ready, while the call is still happening. Which rung fits that job is a field-level engineering choice. It is not a statement about how any product is built.
event: note.updated
record: account-482
version: 17“Renewal date moved to next quarter.”
Check record identity and version before applying the update.
The direction the field is heading.
We describe the direction, not a roadmap of our own.
Channels that share a connection.
Bootstrapping WebSockets over HTTP/2 (RFC 8441) and continued work on carrying these patterns over HTTP/3 and QUIC, so a long-lived channel shares a connection with everything else instead of monopolizing one.
One-way streams everywhere.
Server-to-client streaming is increasingly the norm for live and incremental experiences, such as token-by-token text and progressive results, pushing SSE and similar one-way streams into everyday use.
Closing the native gap.
Standardized Web Push narrowing the gap between native-app and web notifications, so reaching the person when nothing is open works across more surfaces.
Better backpressure.
Multiplexed transports giving servers finer control over how fast they feed each client, which matters when one machine carries many live connections at once.
The specs behind this page.
- Loreto, Saint-Andre, Salsano, Wilkins (2011). Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP. IETF, RFC 6202.
- WHATWG. Server-sent events. HTML Living Standard, §9.2.
- Fette, Melnikov (2011). The WebSocket Protocol. IETF, RFC 6455 (STD 34).
- Thomson, Damaggio, Raymor (2016). Generic Event Delivery Using HTTP Push. IETF, RFC 8030.
- Thomson, Benfield, eds. (2022). HTTP/2. IETF, RFC 9113.
- McManus (2018). Bootstrapping WebSockets with HTTP/2. IETF, RFC 8441.
Keep reading.
Sibling explainers in the Research section, on the latency and systems that put freshness to work.
Talk. Done.
The field is about one thing: getting what is true now to the screen, fast. See what that feels like on a real call.
No app required. Just your phone number.