Long polling vs WebSockets
Long polling and WebSockets both get server updates to a client without the client asking over and over. Long polling holds an ordinary HTTP request open until the server has something to send, then closes it and the client immediately reconnects. A WebSocket upgrades one connection and keeps it open for messages in both directions.
How long polling works
The client sends a normal HTTP request. Instead of answering right away with "nothing new", the server parks the request, often for 30 seconds or more, until an event arrives or the timeout expires. Then it responds, the connection closes, and the client sends the next request straight away.
To the user it feels like a push. Underneath it is a series of ordinary requests, each carrying a full set of HTTP headers and, if you use cookies or bearer tokens, the authentication work that goes with them. Nothing about this needs special infrastructure: every HTTP server, proxy, and load balancer already handles it. That is why long polling was the fallback before WebSocket support was universal, and why libraries like Socket.IO still fall back to it. It differs from short polling only in that the server waits instead of answering empty-handed.
How WebSockets work
A WebSocket starts as an HTTP request carrying an Upgrade: websocket header. Once the server accepts, the same TCP connection switches to the WebSocket protocol (ws:// or wss://) and stays open. Either side can send a message at any moment, framed with a couple of bytes of overhead rather than a header block, and nothing has to be re-established between messages.
That suits any case where the client talks back: multiplayer games, collaborative editors, trading screens, chat where typing indicators travel up while messages travel down.
Latency and connection cost
WebSockets win on per-message latency because the connection is already there. Long polling adds a reconnect between every update, so a client can miss events that fire in the gap unless the server buffers them, and it pays TCP and TLS setup repeatedly unless keep-alive holds the socket.
The cost trade runs the other way. Long polling leaves a request in flight per client, which ties up a worker or connection slot in servers that map requests to threads. WebSockets hold an open socket per client, cheap in memory but stateful: your load balancer must support the upgrade and sticky routing, and reconnect logic after a network drop is yours to write. Neither scales for free; they just fail in different places.
When long polling is still the right choice
Pick long polling when updates are infrequent, when the traffic is genuinely one-way, or when the network between you and your users is hostile to upgrades. Corporate proxies and older CDNs sometimes strip the Upgrade header or close idle sockets, and a long-polling client keeps working where a WebSocket keeps reconnecting.
If updates flow only from server to client, server-sent events usually beat both: SSE gives you a persistent stream over plain HTTP with automatic reconnection and no upgrade to negotiate. We compare the two directly in WebSocket vs SSE.
Server-to-server events are a different problem
Both techniques assume a client that stays connected and waits. When one backend needs to tell another that something happened, holding connections open between them is wasteful, and neither side wants to reconnect through the other's deploys. That is what webhooks are for: the sender makes a short HTTP request to the receiver only when there is an event to report, and retries it if the receiver is down. We cover that comparison in webhooks vs long polling.
Plenty of products use both layers. A browser gets its live updates over a WebSocket, while the services behind it exchange events through webhooks. If you are building the outbound side of that, sending events to your own customers with signatures, retries, and delivery logs, [Svix]https://www.svix.com/?utm_source=resources&utm_medium=content) provides the infrastructure so you do not have to.
Ready to send webhooks?
Svix handles signing, retries, rate limiting, and delivery observability for the webhooks you send to your users, so your team can stay focused on your product.
Start sending webhooks with Svix or read the build vs. buy analysis