WebSockets vs Server-Sent Events
Server-Sent Events (SSE) is a standardized, unidirectional server-to-client push mechanism built entirely on plain HTTP, using the text/event-stream MIME type and the browser's EventSource API. Unlike WebSockets, which require a protocol upgrade and support bidirectional messaging, SSE only lets the server push data to the client — but in exchange it gets automatic reconnection handling built into the browser for free.
Cricket analogy: Like a stadium's PA system broadcasting score updates one-way to every fan (SSE), versus a two-way radio link between the captain and coach where both can speak (WebSockets).
How Server-Sent Events Work
An SSE stream sends plain-text 'data:' lines terminated by a blank line, and each event can carry an optional 'id:' field. The browser's EventSource object automatically reconnects if the connection drops, and it remembers the last event ID it received, sending it back to the server in a Last-Event-ID header so the server can resume the stream from where it left off instead of replaying everything.
Cricket analogy: Like a scoreboard operator numbering each update ('over 14.3: 4 runs') so if the feed cuts out, it can resume exactly from over 14.3 instead of replaying the whole innings.
// Server (Express)
app.get('/events', (req, res) => {
res.set({
'Content-Type': 'text/event-stream',
'Cache-Control': 'no-cache',
Connection: 'keep-alive',
});
res.flushHeaders();
let id = 0;
const timer = setInterval(() => {
id++;
res.write(`id: ${id}\n`);
res.write(`data: ${JSON.stringify({ price: getLatestPrice() })}\n\n`);
}, 1000);
req.on('close', () => clearInterval(timer));
});
// Client
const source = new EventSource('/events');
source.onmessage = (event) => {
const data = JSON.parse(event.data);
updateTicker(data.price);
};
source.onerror = () => console.log('Reconnecting automatically...');Directionality: The Key Difference
The defining distinction is direction: WebSockets let the client send data back over the same connection at any time, while SSE only pushes data from server to client — if the client needs to send something, it must issue a separate ordinary HTTP request (like a POST). This makes SSE a great fit for notification feeds, live dashboards, and stock tickers, while chat apps, multiplayer games, and collaborative editors genuinely need bidirectional traffic.
Cricket analogy: Like a sports app that streams ball-by-ball commentary to your phone (SSE) but requires a separate button tap through a normal form to submit your own prediction (a plain POST), versus a live commentary chat where you can also shout back live (WebSockets).
SSE runs over plain HTTP/1.1 or HTTP/2 and benefits from HTTP/2's multiplexing, avoiding the browser's classic limit of six concurrent connections per origin on HTTP/1.1. Because it's just HTTP, SSE traffic passes through existing proxies, load balancers, and caches far more transparently than a WebSocket's protocol upgrade.
Choosing Between Them
The deciding factor is usually simple: if the client only needs to receive updates, SSE's simplicity, automatic reconnection, and HTTP-friendliness make it the lower-effort choice. If the client also needs to send frequent, low-latency data back — position updates in a game, keystrokes in a collaborative editor — WebSockets' bidirectional channel is worth the added complexity.
Cricket analogy: Like choosing between a one-way stadium tannoy (good enough for score updates to fans) and a two-way team radio (needed when the captain must actually respond to the coach's instructions mid-over).
SSE only transmits UTF-8 text — there's no built-in way to send binary data like WebSockets' binary frames support. It's also not supported by some older browsers (notably legacy Internet Explorer) without a polyfill, so check your target browser matrix before committing to EventSource.
- Server-Sent Events (SSE) push data one-way from server to client over a standard HTTP connection using the EventSource API.
- WebSockets provide full-duplex, bidirectional communication over a dedicated upgraded connection.
- SSE automatically reconnects and can resume from the last received event ID using the Last-Event-ID header.
- If a client only needs updates pushed to it, SSE is simpler than standing up a WebSocket server.
- SSE only supports text (UTF-8) payloads, while WebSockets support both text and binary frames.
- SSE benefits from ordinary HTTP infrastructure like proxies and caches more easily than WebSockets do.
- Choose WebSockets when the client must also send frequent, low-latency data back to the server.
Practice what you learned
1. What is the primary directional limitation of Server-Sent Events?
2. Which browser API is used to consume a Server-Sent Events stream?
3. What MIME type does an SSE response use?
4. What built-in feature does SSE offer that WebSockets do not provide natively?
5. For which use case would WebSockets clearly be preferred over SSE?
Was this page helpful?
You May Also Like
What Are WebSockets?
An introduction to the WebSocket protocol, a persistent, full-duplex communication channel over a single TCP connection used for real-time web applications.
WebSockets vs HTTP Polling
A comparison of WebSockets against short and long HTTP polling techniques for achieving near-real-time updates in web applications.
WebSocket Frames Explained
A look under the hood at how WebSocket messages are broken into binary frames, including opcodes, masking, fragmentation, and control frames.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics
Web DevelopmentNext.js Study Notes
JavaScript · 30 topics