SSE vs Polling vs Long Polling: Real-Time Data Techniques
What Are They?
All three technologies are ways to get data from server in browser. They allow updating client in real or near real-time, especially when WebSockets aren't available.
Polling (Regular Polling)
Client periodically polls server: "Anything new?"
How Polling Works:
- Client sends
GET /data - Server immediately responds (even if nothing changed)
- After X seconds client sends request again
setInterval(() => {
fetch('/data')
.then(res => res.json())
.then(data => console.log(data));
}, 5000); // Request every 5 sec
Polling Cons
- Constant server load (many "empty" requests)
- Data arrives with delay
- Poor scalability
Long Polling (Long Polling)
Improved version of regular polling: request lives until new data appears.
How Long Polling Works:
- Client makes request
- Server waits for data to appear (or timeout expires)
- Returns data → client immediately sends next request
function longPolling() {
fetch('/data')
.then(res => res.json())
.then(data => {
console.log(data);
longPolling(); // Loop continues
});
}
longPolling();
Long Polling Pros
- Fewer "empty" requests
- Data arrives almost instantly
- Doesn't require new technology (works over regular HTTP)
Long Polling Cons
- Data arrives with delay
- Poor scalability
Server-Sent Events (SSE)
SSE is persistent connection through which server sends data to client when it wants.
This is unidirectional connection: server → client only
How SSE Works
- Client creates
EventSource - Server sets
text/event-stream - Server can send messages without client request
Example (Client)
const eventSource = new EventSource('/events');
eventSource.onmessage = (event) => {
console.log("New message:", event.data);
};
Example (Express Server)
app.get('/events', (req, res) => {
res.setHeader('Content-Type', 'text/event-stream');
res.setHeader('Cache-Control', 'no-cache');
res.setHeader('Connection', 'keep-alive');
setInterval(() => {
res.write(`data: ${JSON.stringify({ time: new Date() })}\n\n`);
}, 3000);
});
SSE Advantages
- Simple implementation
- Works over single connection
- Ideal for notifications, chats, data streaming
- Works even through proxies (supports HTTP/2)
Comparison
| Method | Direction | Persistent Connection | Instantness | Complexity | Support |
|---|---|---|---|---|---|
| Polling | Client → Server | No | No | Simple | All |
| Long Polling | Client → Server | Temporary | Almost | Medium | All |
| SSE | Server → Client | Yes | Yes | Medium | Almost all (except IE) |
What to Choose?
- Polling: if you can't use other methods or it's not critical (e.g., update every 30 sec)
- Long Polling: if data must arrive immediately, but you can't use SSE or WebSocket
- SSE: for unidirectional real-time (chats, notifications, news feeds)
- WebSocket: for bidirectional communication — games, collaborative editors, video chats, chats, etc.
Conclusion:
Polling is simple but inefficient. Long Polling is compromise. SSE is excellent solution for real-time without using WebSocket. Choice depends on communication direction, load, latency requirements and browser support.