Long Polling, Server-Sent Events, WebSockets, and QUIC — four ways to keep your clients in sync. Here's exactly how they work, when to use them, and what you're giving up.
Long Polling
Long polling is HTTP pretending to be real-time.
The client makes a normal HTTP request, but the server holds it open — sometimes for seconds or even minutes — until it has data to send. Once the response arrives, the client immediately fires off the next request.
It's a clever trick, and it works everywhere HTTP works. That's its superpower. But every message costs a full request/response cycle, header overhead and all.
How it works: Client polls -> Server waits -> Data arrives -> Server responds -> Connection closes -> Client immediately polls again.
Best for
- Legacy system compatibility
- Low-frequency updates
- Strict corporate firewalls
- Simple fallback mechanism
Pros
- Works everywhere, any proxy
- No special server setup
- Easy to understand
- Firewall friendly ### Cons
- HTTP overhead (new HTTP request each time)
- Not truly real-time
- Heavy on server resources
- Doesn’t scale well
Server-Sent Events (SSE)
SSE creates one persistent HTTP connection where the server streams a series of events down it indefinitely using a simple text format. The browser handles reconnection automatically.
It's unidirectional: server pushes, client listens.
Best for
- AI token streaming (ChatGPT-style)
- Live notifications
- Stock tickers
- CI/CD log tailing
Pros
- Lightweight
- Built in Auto-reconnect
- Easy to implement
- Great for notifications, dashboards
Cons
- Unidirectional
- Limited binary support
- Not ideal for chat or gaming
WebSocket
WebSocket is what most developers reach for when they say "real-time."
It starts as an HTTP request, performs a protocol upgrade handshake and then becomes a persistent, full-duplex TCP connection. Both sides can send frames at any time, with minimal overhead.
Best for
- Multiplayer games
- Collaborative editing (Figma, Notion)
- Live chat
- IoT device control
Pros
- Full-duplex
- Low latency
- Supports binary
Cons
- Harder to scale
- Needs load balancer config
- No automatic reconnection
QUIC (HTTP/3)
QUIC is a modern transport protocol built on UDP, developed by Google. It powers HTTP/3.
QUIC bakes TLS 1.3 into the protocol itself and introduces independent stream multiplexing that eliminates TCP's core flaw: head-of-line blocking.
With TCP, a single lost packet blocks every stream behind it. QUIC streams are truly independent — one dropped packet only stalls its own stream.
Best for
- High-performance games
- High quality Video streaming (YouTube, Cloudflare)
- Latency-sensitive APIs
Pros
- Faster than TCP
- Better mobile performance
- Handles packet loss better
- Future of web transport
Cons
- Complex
- Server infrastructure still maturing
- WebTransport API still early
Example codes : https://github.com/rizwanc018/lp_sse_ws_quic
Top comments (0)