Long Polling vs SSE vs WebSocket

How It Works

The web was built on a simple model: the client asks, the server answers. But modern applications need the server to push data to the client — chat messages, notifications, live scores, AI token streams, collaborative edits. Three techniques evolved to solve this, each from a different era of web development and with fundamentally different trade-offs.

Long Polling: The Original Hack

Long polling emerged in the mid-2000s when developers realized they could abuse HTTP's connection model. Instead of the server responding immediately, it holds the request open until it has something to send.

// Client-side long polling
async function longPoll() {
  try {
    const response = await fetch('/api/updates?since=' + lastEventId);
    const data = await response.json();
    
    lastEventId = data.lastId;
    handleUpdates(data.events);
  } catch (err) {
    // Wait before retrying on error
    await new Promise(resolve => setTimeout(resolve, 3000));
  }
  
  // Immediately reconnect for next batch
  longPoll();
}

longPoll();

// Server-side (Express)
app.get('/api/updates', async (req, res) => {
  const since = req.query.since || 0;
  
  // Check if data is already available
  let events = await getEventsSince(since);
  
  if (events.length > 0) {
    return res.json({ events, lastId: events.at(-1).id });
  }
  
  // Wait for new data (with timeout)
  const timeout = setTimeout(() => {
    res.json({ events: [], lastId: since });
  }, 30000); // 30-second timeout
  
  eventEmitter.once('newEvent', (event) => {
    clearTimeout(timeout);
    res.json({ events: [event], lastId: event.id });
  });
});

The cycle is: request → server holds → response arrives → client immediately reconnects. This creates the illusion of server push, but every event requires a full HTTP request/response cycle with headers.

When long polling is actually the right choice:

• Firewalls block WebSocket and the SSE polyfill does not work
• Maximum compatibility is required (works in literally every HTTP client)
• Events are infrequent (once per minute) and the reconnection overhead is negligible
• The team is building a quick prototype and does not want to set up WebSocket infrastructure

Server-Sent Events: HTTP-Native Push

SSE is what long polling was trying to be. The client opens one HTTP connection, and the server streams events over it indefinitely.

// Client: trivially simple
const source = new EventSource('/api/stream');

source.onmessage = (event) => {
  const data = JSON.parse(event.data);
  updateUI(data);
};

// Auto-reconnects on disconnect
// Sends Last-Event-ID header on reconnect
// Handles event types, retry intervals — all built in

// Server
app.get('/api/stream', (req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive',
  });

  const send = (data, id) => {
    res.write(`id: ${id}\ndata: ${JSON.stringify(data)}\n\n`);
  };

  const handler = (event) => send(event, event.id);
  eventBus.on('update', handler);

  req.on('close', () => eventBus.off('update', handler));
});

SSE delivers everything long polling tried to achieve but with zero reconnection overhead, built-in event IDs for resumption, and the server controls the timing completely.

WebSocket: The Full Duplex Channel

WebSocket starts as HTTP, then upgrades to a completely different protocol. After the handshake, HTTP is gone — what remains is a raw bidirectional byte pipe with minimal framing.

// Client
const ws = new WebSocket('wss://api.example.com/ws');

ws.onopen = () => {
  ws.send(JSON.stringify({ type: 'subscribe', channel: 'trades' }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  handleMessage(data);
};

ws.onclose = (event) => {
  // Application must handle reconnection
  console.log(`Closed: ${event.code} ${event.reason}`);
  setTimeout(reconnect, 1000 * Math.min(attempts++, 30));
};

The upgrade handshake:

GET /ws HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

After this handshake, both sides can send frames at any time. No request/response. No headers per message. Just 2-14 bytes of framing overhead per message.

The Decision Matrix

This is the comparison table that matters when making an architecture decision:

Criterion	Long Polling	SSE	WebSocket
Direction	Server → Client (simulated)	Server → Client	Bidirectional
Latency	Medium (reconnect gap)	Low (persistent stream)	Lowest (always open)
Complexity	Low (just HTTP)	Low (EventSource API)	Medium (protocol upgrade, reconnect logic)
Scalability	Poor (constant reconnections)	Good (one connection per stream)	Good (one connection, but stateful)
Proxy compatibility	Excellent (plain HTTP)	Good (HTTP, but buffering proxies can interfere)	Poor (requires Upgrade header support)
Auto-reconnect	Manual (implement it)	Built-in (with Last-Event-ID)	Manual (implement it)
Binary support	Yes (as base64)	No (text only)	Yes (native binary frames)
HTTP/2 multiplexing	Yes	Yes (multiple streams, one TCP)	No (uses its own framing)
Browser support	Universal	All modern browsers	All modern browsers
Firewall friendly	Yes (plain HTTP)	Yes (plain HTTP)	Sometimes no (Upgrade blocked)
Per-message overhead	~300 bytes (full HTTP headers)	~5 bytes (data: + newlines)	2-14 bytes (frame header)
Max connections per domain	6 (HTTP/1.1)	6 (HTTP/1.1), unlimited (HTTP/2)	Not limited by HTTP

Real Architecture Decisions

Here is how this decision plays out for real products:

Notification System (Slack-like)

Choose: WebSocket. Users both send and receive messages. The client sends typing indicators, read receipts, and messages. The server pushes messages from other users. Bidirectional is essential.

Live Dashboard (Grafana-like)

Choose: SSE. Data flows one way — the server pushes metric updates. The client only consumes. SSE's auto-reconnect and Last-Event-ID ensure no data gaps. Multiple SSE streams multiplex over HTTP/2.

AI Chat Interface (ChatGPT-like)

Choose: SSE. The user sends a prompt via POST request. The server streams tokens back via SSE. During generation, communication is strictly one-way. The next prompt is a new POST request.

Collaborative Editor (Google Docs-like)

Choose: WebSocket. Both users send edits simultaneously. Operations must be applied in near-real-time in both directions. The operational transform or CRDT protocol requires bidirectional low-latency messaging.

Stock Ticker (Bloomberg-like)

Choose: WebSocket. Sub-millisecond latency matters. Binary data (packed price updates) is efficient. Traders also send orders through the same connection. The infrastructure team can configure proxies to support WebSocket.

Legacy Enterprise App

Choose: Long Polling. The corporate proxy blocks WebSocket upgrades. SSE works but IT has not approved the content type. Long polling is plain HTTP and works through every proxy, firewall, and security appliance.

Scaling Considerations

Each approach has different operational characteristics at scale:

Long Polling at Scale: Each "push" costs a full HTTP request/response. With 100,000 connected users and 1 event per second, that is 100,000 HTTP requests per second just for reconnection. The connection churn is expensive. Facebook made this work in the early days with their Erlang-based Comet server, but it was not pleasant.

SSE at Scale: 100,000 persistent connections, each consuming a file descriptor and a small amount of memory. Node.js handles this well with its event loop. The key challenge is that if a server process restarts, all clients reconnect simultaneously (thundering herd). Implement jittered reconnection using the retry field.

# Send a random retry interval to spread reconnections
retry: 3000  # Client A reconnects in 3s
retry: 5000  # Client B reconnects in 5s
retry: 4000  # Client C reconnects in 4s

WebSocket at Scale: Similar to SSE in terms of persistent connections, but WebSocket connections are stateful — they often carry session data, authentication state, and subscription information. This makes horizontal scaling harder because connection state must be considered when routing. Use a pub/sub backbone (Redis, NATS) to propagate events across server instances.

The HTTP/2 Factor

HTTP/2 significantly changes the SSE vs WebSocket calculus. Under HTTP/1.1, each SSE stream consumed one of the browser's 6-per-domain connections. Three SSE streams meant only 3 connections left for API calls.

HTTP/2 multiplexes all streams over a single TCP connection. A single browser tab can sustain 100 SSE streams without consuming additional connections. This eliminates SSE's biggest operational limitation and makes it viable for complex dashboards with many independent data streams.

WebSocket does not benefit from HTTP/2 multiplexing. After the upgrade handshake, it operates on its own framing protocol over a dedicated TCP connection. Each WebSocket connection is still a separate TCP socket.

This is why the industry trend is shifting back toward SSE for server-push use cases. It is simpler, more compatible, and with HTTP/2, more efficient. Reserve WebSocket for genuine bidirectional needs — fewer use cases require it than most teams expect.