Long Polling vs SSE vs WebSockets

Also Known As

TL;DR

Explanation

Long polling: client holds HTTP request open, server responds when data is available, client reconnects immediately. Simple but high latency from reconnect overhead. SSE: browser opens persistent connection, server pushes text events with built-in reconnection and event IDs. One-directional, HTTP-compatible. WebSocket: full-duplex TCP after HTTP upgrade — bidirectional, binary and text, low latency. PHP: SSE with chunked transfer encoding + flush(). WebSockets via ReactPHP or Ratchet.

Common Misconception

Why It Matters

Common Mistakes

• Long polling with short timeouts — defeats the purpose
• SSE without event IDs — client misses events during disconnection
• WebSocket when SSE suffices — added complexity for no benefit
• No heartbeat — proxies close idle connections after 30-90 seconds

Code Examples

// 1 request per second per user — expensive:
setInterval(() => {
    fetch('/api/updates').then(r => r.json()).then(update);
}, 1000);

// SSE — persistent, automatic reconnection:
// PHP:
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');
header('X-Accel-Buffering: no'); // Disable nginx buffering
while (true) {
    echo "id: {$id}\ndata: " . json_encode(getLatest()) . "\n\n";
    ob_flush(); flush();
    if (connection_aborted()) break;
    sleep(1);
}

// JavaScript:
const es = new EventSource('/api/stream');
es.addEventListener('update', e => update(JSON.parse(e.data)));

References

• ↗ https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events

Tags

Related Terms