TL;DR

SSE is a one-way stream from server to browser over plain HTTP — simpler than a [[websocket]], far more efficient than [[http-polling]], and enough for delivering chat messages to a widget.

Key Points

✓

SSE is part of the HTML standard and is consumed in the browser through the built-in EventSource API — no library required [1][2].

✓

It is one-directional: the server streams to the browser, while the browser sends messages back with ordinary HTTP requests [1].

✓

The browser reconnects automatically if the stream drops, and replays from a Last-Event-ID header so no messages are lost in the gap [1][2].

✓

SSE rides on normal HTTP, so it passes through proxies, CDNs, and corporate firewalls that sometimes block a [[websocket]] upgrade.

✓

The payload is UTF-8 text only; binary data has to be encoded, which is rarely a limitation for a [[chat-message]].

✓

Compared with [[http-polling]], SSE removes the tradeoff between latency and request volume — updates arrive the moment they exist.

How SSE works

The browser opens a normal GET request to an endpoint that responds with the content type text/event-stream and then simply never finishes the response ^[1]. The server writes events into that open connection as they occur, each one a small block of text with optional event, data, and id fields, separated by a blank line. On the client, EventSource turns each block into a DOM event you can listen to. Because the connection stays open, there is no request overhead per message and no delay waiting for the next poll. Servers typically send a comment line every 15–30 seconds as a heartbeat, which keeps intermediaries from treating the idle connection as dead. If the connection does break, the browser reconnects on its own and sends the id of the last event it saw, so the server can resume exactly where it left off ^[2].

SSE versus WebSocket versus polling

The three transports solve the same problem with different tradeoffs. HTTP Polling is the simplest and works everywhere, but every visitor generates a steady drip of requests and a message can sit unseen for as long as the poll interval. A WebSocket gives true bidirectional, low-latency messaging, but it requires a protocol upgrade that some proxies mishandle, and the server has to manage its own reconnection, heartbeat, and message-replay logic. SSE lands in between: it is plain HTTP, gets automatic reconnection and replay for free from the browser, and costs one connection per visitor instead of one request per second. The one thing it cannot do is carry messages upward — but a chat widget does not need it to, because sending a message is a natural fit for a REST API call.

Why it matters for a chat widget

A Live Chat Widget has an asymmetric traffic pattern. Visitors send a handful of messages per Conversation, but they need to receive replies instantly, and most of the time the widget is open with nothing happening at all. SSE fits that shape precisely: one idle connection costs almost nothing, a reply appears the moment the operator sends it, and a visitor who switches networks or wakes their laptop is reconnected and caught up without any code in the widget doing the work. That reliability matters more than raw speed for First Response Time (FRT) — a message that arrives late because a socket silently died is worse than one that arrives a second slower. It also keeps the widget bundle small, which protects the host site's Core Web Vitals.

Sources & References

HTML Living Standard — Server-sent events ↗

Using server-sent events - MDN Web Docs ↗

Last updated: August 12, 2026

Related Terms

WebSocket

WebSocket is a protocol (standardized as RFC 6455) that opens a single, persistent, full-duplex connection between a browser and a server, letting either side push data at any time without re-issuing HTTP requests. It is the transport many real-time apps reach for when they need low-latency, bidirectional messaging.

HTTP Polling

HTTP polling is a real-time technique where the client repeatedly sends HTTP requests on a fixed interval to ask the server whether new data is available, instead of holding a persistent connection. Eloqra's chat widget uses short polling roughly every 4-5 seconds to fetch new messages and typing state.

Webhook

A webhook is a user-defined HTTP callback: instead of polling for data, an application registers a URL that a source service calls with an HTTP POST request the moment a specific event happens. [1] In Eloqra, a webhook is how an operator's Telegram reply travels back into the chat widget.

REST API

A REST API is a web interface that lets two systems exchange data over HTTP by treating each piece of data as a resource addressed by a URL and acted on with standard methods like GET, POST, PUT, and DELETE. It follows the Representational State Transfer architectural style, which favors stateless, uniform, cacheable interactions between client and server.

JavaScript Widget

A JavaScript widget is a self-contained chunk of front-end code, loaded from a single script tag, that injects an interactive UI into any third-party web page. In Eloqra it is the live-chat widget that boots from one snippet and renders the chat launcher and conversation panel directly on a customer's site.

Live Chat Widget

A live chat widget is the embeddable, in-browser chat interface a website loads from a small script so visitors can message a business in real time without leaving the page. In Eloqra it is a floating launcher and chat panel that boots from a single <script> tag and renders inside a Shadow DOM.

Put live chat on your site in 30 seconds

Eloqra gives you a lightweight live chat widget that routes every visitor message to your Telegram — free while in early access.

Get Started Free

Server-Sent Events (SSE)