Choosing Between Polling, Long Polling, WebSocket, and SSE for Real‑Time Frontend Apps

Background

In scenarios that require real‑time data such as push notifications, stock quotes, chat messages, logs, or learning status, low latency is essential. The most common solution is polling, but long connections (WebSocket) and server‑sent events (SSE) are also available.

Polling

Polling repeatedly sends HTTP requests to fetch the latest data.

Short polling

Short polling (also called polling) works like a normal request with a timer or useRequest configuration. Each request returns immediately; the client repeats the request at a fixed interval.

Advantages: simple to implement. Disadvantages: many useless requests and uncontrolled real‑time performance.

Excessive useless requests – the server may return identical or empty data, causing repeated DB queries and re‑rendering.

Real‑time latency is bounded by the polling interval.

Long polling

Long polling keeps the request open on the server until new data arrives or a timeout (typically 30‑60 s) occurs. When data becomes available, the server responds, and the client immediately issues a new request.

Advantages: reduces useless requests and improves timeliness. Disadvantages: consumes server resources by holding connections and can be inefficient when data updates frequently.

Server resources are heavily used because each held request occupies a thread or connection.

Frequent data changes cause many connection creations, adding overhead compared with WebSocket or SSE.

Long connection – WebSocket

WebSocket establishes a persistent, full‑duplex connection after an HTTP handshake. Both client and server can push messages at any time.

Request characteristics

HTTP/1.1 GET request

Connection: Upgrade

Upgrade: websocket

Sec‑WebSocket‑Key: base64‑encoded random 16‑byte string

Sec‑WebSocket‑Protocol: optional sub‑protocol

Origin header

Response characteristics

Status code 101 Switching Protocols

Upgrade / Connection / Sec‑WebSocket‑Protocol echo the request

Sec‑WebSocket‑Accept generated from the request key

WebSocket is widely supported by all modern browsers.

Simple WebSocket implementation

// Connect
const ws = new WebSocket(`wss://${url}`);
// Send message
ws.send("Message: " + count);
// Receive message
ws.onmessage = function(event) {
  console.log(event.data);
};
// Close
ws.close();

Using WebSocket in a project

Typical concerns include authentication, heartbeat, user identification, logging, and monitoring online connections.

Server‑Sent Events (SSE)

SSE is part of the HTML5 specification. The server sends a text/event-stream response, and the browser receives it via the EventSource API. SSE is unidirectional (server‑to‑client) and transports only text.

Comparison with WebSocket

SSE

WebSocket

Unidirectional

Bidirectional

Text only

Binary and text

Standard HTTP

WebSocket protocol

Compatibility

All major browsers support SSE.

Data format

Each SSE message consists of fields such as data, event, id, and retry, separated by blank lines.

// Example
: this is a test stream

retry:1000

event: customMessage

data: some text

data: another message
data: with two lines

Simple SSE implementation

Client side

const source = new EventSource(url, { withCredentials: true });
source.onmessage = function(event) {
  // handle message
};
source.onerror = function(event) {
  // handle error
};
source.close();

Server side (Node.js)

res.writeHead(200, {
  "Content-Type": "text/event-stream",
  "Cache-Control": "no-cache",
  "Connection": "keep-alive",
  "Access-Control-Allow-Origin": "*"
});
res.write("retry: 10000

");
res.write("event: connecttime

");
res.write("data: " + new Date() + "
");
setInterval(() => {
  res.write("data: " + new Date() + "

");
}, 1000);

References

RFC 6455

WebSocket protocol Chinese version

Deep dive into WebSocket principles (Zhihu)

HTTP long connection implementation (Juejin)

WebSocket API (MDN)

EventSource API (MDN)