0% completed
Difference Between Long-Polling, WebSockets, and Server-Sent Events
On This Page
Compare the choices
How to choose
Explain the choice
Long polling, WebSocket, and Server Sent Events all help an app show new information without a page refresh.
- Long polling: The client asks for news. The server waits to answer, then the client asks again.
- WebSocket: The client and server keep one connection open and can both send messages.
- SSE: The client asks for a stream, and the server sends a series of text events in its response.
All three need a plan for broken connections and missed messages.
Related reading: Long Polling, WebSocket, Server Sent Events (SSE).
Compare the choices
| Question | Long polling | WebSocket | SSE |
|---|---|---|---|
| How does the browser receive updates? | Repeated HTTP requests that may wait | Messages on one open connection | Text events in one open HTTP response |
| Can the browser send data back? | Yes, with an HTTP request | Yes, on the same connection | Yes, with a separate HTTP request |
| What happens after a response? | The client asks again | The connection usually stays open | The response usually stays open |
| Who handles reconnecting? | App code | App code | EventSource usually tries automatically |
| Good starting case | Simple notifications or a fallback | Frequent messages both ways | Mostly server updates such as scores or progress |
How to choose
Ask what messages your app sends and how often. For a busy shared game, WebSocket may fit because both sides send frequent updates. For a progress bar, SSE may fit because most updates go from server to browser. For simple notifications in a system that already uses ordinary HTTP requests, long polling may be enough.
The network and server also matter. Test whether proxies keep connections open, how many clients will stay connected, and what happens after a disconnect. Do not assume one choice is always fastest or always works on every network.
Explain the choice
For a live score page, you might say: "The server sends small text updates. SSE gives the browser a stream, and we can use event IDs to help it catch up after reconnecting."
For a shared game, you might say: "Players and the server send frequent messages both ways. WebSocket gives them one open channel. We must handle reconnecting and missed state."
For simple notifications, long polling may be easier to add to a service that already uses HTTP requests. If it holds many requests open, check server capacity.
Key takeaway: Pick a method based on message direction, frequency, server capacity, and the way it recovers from a broken connection. Test it in the network where people will use it.
Vu Tong
· 5 months ago
It's worth to mention that to avoid performance impact, the server should have some kind of asynchronous processing for incoming requests. If the server uses a traditional thread-per-request model and every client holds a long-lived connection, that will hurt the overall performance.
dominikcubic
· 3 years ago
In this description of AJAX polling, is the "requested webpage" the same as the "Client"?
- Client requests data from a server using regular HTTP.
- The requested webpage opens a connection to the server.
- The server sends the data to the client whenever there's new information available.
heybenross
· 3 years ago
When should each be used? What are the pros and cons of each?
Reading Progress
0%
On This Page
Compare the choices
How to choose
Explain the choice