Long Polling vs SSE

Long polling and Server-Sent Events (SSE) are both mechanisms for server-push communication over HTTP. Long polling simulates push by holding HTTP requests open. SSE provides native push through a persistent streaming connection.

Long Polling Mechanics

The client sends a request. The server holds it open until data is available or a timeout occurs. Upon receiving a response, the client immediately sends a new request. This cycle creates a near-real-time push effect but with reconnection overhead after every response.

SSE Mechanics

The client opens a connection using the EventSource API. The server keeps the connection open and sends events as they occur in a simple text format. The connection stays open indefinitely, and the browser automatically reconnects if it drops, resuming from the last received event ID.

Why SSE Is Better for Server Push

SSE is purpose-built for server-push scenarios. It eliminates the reconnection churn of long polling, provides automatic resume with last-event-id, and has lower overhead since HTTP headers are sent only once. The EventSource API is simpler to use than managing polling logic.

When Long Polling Is Still Useful

Long polling works behind proxies that buffer streaming responses (breaking SSE). It also works in extremely old browsers. Some architectures use long polling as a fallback when SSE connections fail.

For more on real-time communication patterns, see our concepts library and system design interview guide. Explore pricing for practice.

The Bottom Line

Prefer SSE for server-push use cases — it is more efficient and has better built-in features. Fall back to long polling only when infrastructure constraints prevent SSE connections.