WebSockets vs SSE vs Long Polling — Real-Time Without the Panic

Most developers reach for WebSockets by default. That’s usually wrong.

Not because WebSockets are bad — they’re excellent at what they do. But they carry real infrastructure overhead: sticky sessions on load balancers, custom heartbeat logic, authentication workarounds, and proxy configuration that works fine until someone opens your app in a corporate office. For the majority of “real-time” requirements, that overhead isn’t justified.

The short version: if data flows only from server to client, use Server-Sent Events (SSE). If the client needs to push data back with low latency, use WebSockets. If your refresh cadence is measured in seconds and you want the simplest possible deployment, long polling still works — and there’s no shame in that.

Der Vergleich

Long Polling

Long polling is standard HTTP polling where the server holds the request open until it has something to return — or a timeout fires. The client sends a request, the server waits, returns the response when data is available, and the client immediately fires the next request. It’s a loop disguised as a network call.

This is genuinely fine for a range of use cases:

• Notification badges — unread counts that update every 30 seconds don’t need a persistent connection.
• Admin dashboards with relaxed freshness — metrics that update every 15–60 seconds work fine with polling.
• Mobile apps on unreliable connections — persistent connections get killed by aggressive network management; polling reconnects cleanly on each request.
• Behind corporate proxies — many enterprise proxies buffer or terminate non-standard connections. HTTP polling works everywhere, no exceptions.

The scaling caveat is real. Each held-open request occupies a connection slot. On threaded servers this gets expensive; on event-loop servers (Node.js, Tornado, Go with goroutines) it’s manageable but not free. At tens of thousands of concurrent users, the math on server resources starts to matter.

Server-Sent Events (SSE)

SSE is the option most developers skip on their way to WebSockets. That’s a mistake for any use case where data flows in one direction: server to client.

It runs over plain HTTP. The server sets Content-Type: text/event-stream and writes newline-delimited messages to the response body indefinitely. The browser’s native EventSource API handles reconnection automatically — including a Last-Event-ID header so the server can resume a stream after a drop. You get named event types, configurable retry intervals, and no library required.

const source = new EventSource('/api/events');

source.addEventListener('priceUpdate', (e) => {
  const { price, symbol } = JSON.parse(e.data);
  updateTicker(symbol, price);
});

source.onerror = () => {
  // EventSource reconnects automatically — nothing to do here
};

What SSE gets right:

• Standard HTTP — works through load balancers, reverse proxies, and CDNs with zero configuration. No sticky sessions.
• Automatic reconnection — built into the spec. Set the retry: field in the stream to configure the interval; the client handles the rest.
• HTTP/2 multiplexing — removes the old 6-connection-per-domain limit from HTTP/1.1. If you’re on HTTP/2 (you should be), this isn’t a concern.
• Simpler server implementation — keep a connection open and write to it. No protocol handshake, no frame parsing, no heartbeat logic.

The one real limitation: SSE is one-directional. Clients can’t send data through an SSE connection. In practice this is rarely a problem — use regular POST requests for anything the client needs to send, alongside the SSE stream for server events. The two coexist without issues.

The HTTP/1.1 connection limit is worth knowing. Browsers cap at 6 simultaneous connections per domain across all tabs. Three browser tabs each consuming two SSE streams = limit hit. HTTP/2 removes this via multiplexing. If you can’t guarantee HTTP/2 delivery (some older CDN configs, some corporate proxies), keep this in mind.

WebSockets

WebSockets are the right tool when you genuinely need bidirectional, low-latency messaging. The use cases that justify the complexity:

• Chat — messages from every user need to reach others in near-real-time. WebSockets are the standard here for good reason.
• Multiplayer games — game state synchronizes between clients constantly, often at 20–60 updates per second. No other approach gets close to the same per-frame efficiency.
• Collaborative editing — CRDT or OT-based real-time editing (Notion, Figma, Google Docs-style) requires every keystroke to propagate with minimal latency.
• Trading terminals — sub-100ms price feeds with order submission on the same connection. WebSockets were built for this.

The infrastructure costs that SSE and polling avoid:

• Sticky sessions — WebSocket connections are stateful and tied to a single server process. Load balancers need session affinity (IP hash or cookie-based) to route reconnects correctly. Without it, a reconnecting client may land on a server with no knowledge of their session.
• Proxy and CDN config — Nginx, HAProxy, and Cloudflare all support WebSockets but require explicit configuration (Upgrade und Connection headers, proxy_http_version 1.1 in Nginx). Some corporate firewalls block 101 Switching Protocols. You’ll find out about this in support tickets from users at specific offices.
• Authentication complexity — WebSockets can’t set custom headers after the initial handshake. Token auth usually means passing the token in the query string (ugly, common) or in the first message after connection (cleaner, but requires server-side gating logic).
• Heartbeats — the spec doesn’t require keepalives. Without custom ping/pong logic, you won’t detect dead connections until the next message fails. Either implement heartbeats or accept stale connections silently accumulating.

None of these are blockers — they’re solvable. They’re complexity that doesn’t exist with SSE or HTTP polling. If you’re choosing WebSockets for a notification feed or live dashboard, you’re paying that cost for no reason.

How to Choose

Work through these in order:

1. Does the client need to push data to the server at high frequency, or does latency under 200ms matter? No → skip WebSockets.
2. Does data flow only server → client? Yes → SSE is almost certainly the right call.
3. Are you on HTTP/2? If yes, SSE has no meaningful limitations for most use cases. If no, factor in the 6-connection limit.
4. Is your deployment serverless or behind infrastructure that doesn’t support persistent connections? SSE works on most serverless platforms (Vercel, Cloudflare Workers via the Streams API); WebSockets on serverless requires additional plumbing.
5. Is your refresh cadence 15 seconds or more? Long polling. Keep it simple.

If you’ve worked through this and the answer is still WebSockets — good. Now you’re using them for the right reason instead of the default one.

Debugging Event Payloads

SSE data: fields and WebSocket messages almost always carry JSON. When you’re debugging a misbehaving stream, pasting the raw payload into IO Tools’ JSON Formatter is the fastest way to see structure at a glance — especially for nested event objects where a missing bracket or extra comma kills the parse silently.

Das könnte Ihnen auch gefallen

Neu

Makefile for Developers — Automate Tasks Without Bash Spaghetti

Mehr lesen "

Aktualisiert am Mai 21, 2026

Neu

SQL-ERKLÄRUNG-Ausgabe muss nicht wie fremdes Texte aussehen

Mehr lesen "

Aktualisiert am 19. Mai 2026

Neu

SSL/TLS-Zertifikate — Was diese Felder und Ablaufdaten tatsächlich bedeuten

Mehr lesen "

Aktualisiert am 18. Mai 2026

Neu

.env-Dateien — 6 Fehler, die Ihre Geheimnisse auf GitHub bringen

Mehr lesen "

Aktualisiert am 18. Mai 2026