Technical
Server-sent events
Also called SSE.
Server-sent events is a browser feature where one long-lived HTTP response streams text events from the server to the page. Traffic flows one way, server to client.
How it is measured
In DevTools the request has type `eventsource` and stays open. The response is `Content-Type: text/event-stream`, with blocks like `event: tick` and `data: 42` separated by blank lines. The browser's `EventSource` reconnects on its own after a drop and sends `Last-Event-ID`.
Measure open connections on the server, the reconnect rate, and idle timeouts. Proxies often cut a silent connection after 60 seconds, so send a comment line such as `: ping` every 15 to 30 seconds.
Worked example
A deploy-status page opens one SSE stream per viewer. At 300 viewers nginx holds 300 connections, and an app server with a pool of 32 workers is exhausted because each stream pins one. Moving the stream to an async handler lets 300 idle streams share a single process.
A corporate proxy was also cutting silent streams at 60 seconds. A ping comment every 20 seconds keeps them alive, and the reconnect rate drops from 5 a minute to almost none.
How it differs
Server-sent events push one way over ordinary HTTP and reconnect automatically. A WebSocket is two-way over its own upgraded protocol. SSE cannot carry client-to-server messages on the same channel, and WebSocket needs more infrastructure to run.
Common errors
Using it for client-to-server messages. Letting a proxy buffer the stream so nothing arrives until it closes, which needs `X-Accel-Buffering: no`. Forgetting heartbeats. Opening more than six on HTTP/1.1 to one host. Sending no event ids, so reconnects lose messages. Holding one worker per stream.
In practice
Use SSE for dashboards, progress bars, and notifications. Send heartbeats and event ids, disable proxy buffering, and test through the same proxy chain production uses.