Server-Sent Events, Polling and Long Polling: What They Are and When to Use
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.