Common Web Push Technologies and Their Comparison: Short Polling, Long Polling, Iframe Stream, WebSocket, and Server‑Sent Events

The article introduces a real‑time notification requirement for client‑side order messages and explains why synchronizing client and server information is crucial.

1. Push technology implementations

1.1 Short polling – The client uses setInterval or setTimeout to periodically request data. It works on all browsers but can cause UI “freeze” and unnecessary network traffic when data has not changed.

1.2 Long polling – The client sends a request that the server holds until new data is available or a timeout occurs, reducing request frequency but keeping a connection open, which consumes resources and may still suffer from security concerns.

1.3 Iframe stream – A hidden iframe is created; the server pushes JavaScript snippets into the iframe, which call a parent‑page function to update the UI. Example server code: println("<script>父级函数('" + 数据 + "<br>')</script>") Advantages include good browser compatibility; disadvantages are loading indicators in IE/Firefox and server‑side resource overhead.

1.4 WebSocket – A full‑duplex TCP‑based protocol established via an HTTP 101 upgrade. It offers low latency, binary support, and high security, but requires server redeployment and is not supported by very old browsers.

1.5 Server‑Sent Events (SSE) – The client opens a single HTTP connection; the server streams events using the text/event-stream MIME type. It is simple, low‑cost, and works well in modern browsers, though it is not supported by IE.

2. Comparison table (short polling, long polling, WebSocket, SSE) summarises communication protocol, trigger mode, pros, cons, and suitable scenarios.

3. Project selection – For the described scenario (high‑end browsers, server‑to‑client one‑way push), SSE was chosen because it fits the requirements without needing extra server infrastructure.

4. Practical implementation

Orders are placed in Redis; a backend service polls Redis and pushes new messages to the client via SSE. The client receives messages with the onmessage event, and custom events can be handled via addEventListener . Issues such as duplicate messages, page refresh loss, container timeout, and request throttling are addressed with local caching, random identifiers, and HTTP 204 responses.

5. Summary – For simple push needs on modern browsers, SSE is recommended; for bidirectional or binary communication, use WebSocket; for legacy browser support, fall back to short polling.