When Not to Use WebSocket: 7 Real-Time Alternatives and How to Pick

WebSocket is the right default for real-time chat. That sentence belongs in the intro because a lot of “WebSocket alternatives” articles spend 2,000 words implying you should replace it – and for most interactive products, you shouldn’t. The correct mental model is narrower: WebSocket is the right default, and there are specific situations where you should reach past it for a different reason.

If you only need server-to-client pushes – notifications, live dashboards, LLM streaming responses – you’re running a bidirectional socket to carry one-directional traffic. SSE does that job with less overhead and survives more networks. When using IoT, MQTT consumes much less power budget than WebSocket for constrained devices. When connecting backend services, gRPC streaming provides you with typed contracts while JSON-over-WebSocket does not. When you require peer-to-peer, WebRTC DataChannel doesn’t even use your server.

This article covers seven alternatives with real code, honest trade-offs, benchmark numbers, and a decision framework. The goal isn’t to get you off WebSocket, but to tell you when a specific alternative solves a specific problem you’ve measured.

In this article 

• Why look past WebSocket 
• When WebSocket is still the right pick 
• The 7 alternatives, with code 
• Benchmark comparison 
• Decision framework 
• Mistakes when moving off WebSocket 
• Ethora: transport handled for you

Why look past WebSocket

None of the reasons below are academic. Each one maps to a situation where a different transport is measurably better, not just theoretically cleaner.

You only push server → client

WebSocket opens a full-duplex channel even when you’re only using half of it. For notifications, activity feeds, or LLM response streaming, SSE is simpler, cheaper, and survives the corporate proxies and load balancers that occasionally drop the WebSocket upgrade handshake. EventSource is browser-native and has been since 2009 – no library required.

Battery and bandwidth matter

MQTT was built for sensors and actuators where power is measured. A well-configured MQTT broker with QoS 0 uses roughly 2 bytes of per-message overhead versus WebSocket’s ~6 bytes of framing plus TLS overhead. On a mobile device, sending one message every 30 seconds is not trivial across a day. Facebook Messenger’s mobile backend has historically used MQTT instead of WebSocket for exactly this reason.

Corporate network environments

Some enterprise proxies and firewalls still intercept or drop the HTTP/1.1 → WebSocket upgrade. SSE, being plain HTTP, works in environments where WebSocket doesn’t. It’s not as common as in 2015, yet it still bites enough production deployments to be worth knowing about.

Typed backend-to-backend communication

JSON over a WebSocket connection gives you flexibility; it also means schema drift is silent and serialization bugs surface at runtime. For internal services that need to stay in sync on message shape, gRPC streaming on HTTP/2 with protobuf is a materially different architecture – schemas break at compile time, not in production at 2 am.

Peer-to-peer or ultra-low-latency media

WebSocket routes everything through your server, which adds latency and server-side bandwidth cost. WebRTC DataChannel establishes a direct peer-to-peer path – after the initial signaling exchange, your server handles no media. For a two-player game or a 1:1 video call, this is a meaningful difference in both latency and infrastructure cost.

Massive read-heavy fanout

Pushing the same payload to a million simultaneous readers is expensive when each reader holds an open WebSocket connection on your servers. SSE served behind an HTTP cache or CDN, can distribute read-heavy streams without every connection landing on your application layer.

You’re ready to invest in the next wave

WebTransport over HTTP/3 (QUIC) is a W3C specification with production-level Chrome support and experimental Firefox support. Early testing shows 20-40% lower latency than WebSocket for the same workload, since QUIC can handle connection migration (from WiFi to a mobile network) without needing to reconnect, unlike WebSocket. It’s not “ready for prime time use,” but if you’re building a system with a five-year lifetime, it’s good to know what the trend will be.

When WebSocket is still the right default

Before reaching for an alternative, run the honest check: does any of the above actually describe your situation, or are you just interested in the protocol?

WebSocket is correct when you need true bidirectional flow at high frequency – a user types and messages flow in both directions constantly. Live collaboration tools (think Google Docs, Figma), chat applications where users are sending and receiving interleaved, multiplayer game lobbies, real-time presence systems – these are all cases where you’re genuinely using both directions and using them together.

It’s also correct when you already have a working WebSocket stack with no measured problem. “This blog post mentioned MQTT is lighter” is not a reason to rewrite your transport layer. “We measured that 18% of our enterprise users can’t establish WebSocket connections through their proxy” is. The first is interesting reading; the second is a project.

Browser-only apps where you can’t run a native MQTT client are another case where WebSocket stays on top – MQTT over WebSocket is possible, but it adds the wrapper complexity without eliminating the overhead on the browser side.

The actual rule 

Don’t move off WebSocket because a benchmark looked interesting. Move because you measured a specific constraint – battery drain, proxy failures, fanout cost, latency ceiling – that a different transport specifically addresses.

7 Alternatives with Code

Server-Sent Events (SSE)

Use when: one-way push, LLM streaming, notifications 

Skip when: client needs to push back at a high frequency

SSE is a browser-native API (standardized in WHATWG) that opens a long-lived HTTP connection over which the server streams text events. No library. No upgrade handshake. If the connection drops, the browser reconnects automatically using the last received event ID. Anthropic and OpenAI both use SSE for their streaming API responses – if you’re building an LLM feature, SSE is what the upstream API is already sending you.

The main limitation people cite – “clients can’t send” – is not actually a limitation. You send from the client to the server with a regular POST. SSE handles the stream back down. For most notification or streaming scenarios, that’s exactly the right shape.

// Client
const es = new EventSource('/stream');
es.onmessage = (e) => render(JSON.parse(e.data));
es.onerror = () => console.warn('SSE reconnecting...'); // auto-reconnect built in

// Server (Node.js)
res.writeHead(200, { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache' });
res.write(`data: ${JSON.stringify(payload)}\n\n`);

MQTT

Use when: IoT devices, battery-constrained mobile, high-fanout event distribution 

Skip when: browser-native required without a WebSocket wrapper

MQTT is a publish-subscribe protocol from the early 1990s that was formally standardized in MQTT 5.0. The wire overhead is roughly 2 bytes at QoS 0 versus WebSocket’s minimum 6-byte frame header, and the protocol was designed to survive high-latency, lossy connections – which is either IoT in a field or a mobile client on 3G, and the engineering constraints are similar.

There are three Quality of Service tiers: 

• QoS 0 – at-most-once,
• QoS 1 – at-least-once with confirmation, 
• QoS 2 – exactly-once with 4-way handshake. 

For most chatting applications, QoS 1 is appropriate; QoS 2 is too costly and often unnecessary.

Browsers can’t connect to an MQTT broker directly – you need MQTT over WebSocket, which wraps MQTT framing in a WebSocket connection. You lose some of the wire overhead advantage but retain the QoS semantics and pub/sub model. For native mobile clients (iOS, Android), use a native MQTT library directly.

// mqtt.js (browser or Node, over WS)
const client = mqtt.connect('wss://broker.example.com:443/mqtt');
client.subscribe('rooms/42/messages');
client.on('message', (topic, payload) => render(payload.toString()));
client.publish('rooms/42/messages', JSON.stringify(msg), { qos: 1 });

gRPC Bidirectional Streaming

Use when: backend-to-backend services, typed contracts, high-throughput microservices

Skip when: browser-facing; when JSON debuggability matters more than schema enforcement

gRPC runs over HTTP/2 with Protocol Buffers as the default serialization. HTTP/2 multiplexes streams over a single connection – each gRPC call is a stream on that connection, with framing overhead of around 7-10 bytes per message. Bidirectional streaming lets the client and server both push on the same stream. The killer advantage is the protobuf schema: a message shape mismatch breaks at compile time in typed languages, not in production when some edge-case message arrives.

gRPC-Web exists for browsers but has a real constraint: it doesn’t support true bidirectional streaming in the browser. Client streaming and bidi streaming require a proxy (Envoy, grpc-gateway, or the Connect protocol). For browser-facing real-time, WebSocket or SSE remains the better pick. For service-to-service communication inside a backend – a chat server talking to a moderation service, an AI service streaming response tokens to an orchestrator – gRPC is genuinely the stronger choice.

// Node.js gRPC server-side handler (bidirectional stream)
server.addService(ChatService, {
  chat(call) {
    call.on('data', (msg) => {
      broadcast(msg);
      call.write({ text: 'ack', id: msg.id });
    });
    call.on('end', () => call.end());
  }
});

WebRTC DataChannel

Use when: peer-to-peer chat, ultra-low-latency game state, file transfer without server routing 

Skip when: multi-party at scale (you still need an SFU); TURN relay costs are a concern

WebRTC is best known for audio and video, but the DataChannel API carries arbitrary binary or text data over the same peer-to-peer connection. Once the connection is established (via a signaling server you still need to run), media and data flow directly between peers – your server handles no payload bytes, only the initial signaling exchange. For two users on the same continent, this can get latency below 30ms, compared to ~80-120ms via a server relay.

The gotcha is NAT traversal. STUN handles discovery; TURN is the fallback relay when direct P2P fails – which happens on symmetric NAT and strict corporate firewalls, roughly 15-20% of real-world connections. TURN servers relay all the traffic, which costs real bandwidth ($0.05–0.15 per GB depending on the provider). Without TURN, those 15-20% of your users get silent failures.

// After signaling and ICE negotiation
const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.example.com' }] });
const dc = pc.createDataChannel('chat', { ordered: true });
dc.onmessage = (e) => render(e.data);
dc.send(JSON.stringify({ text: 'hello' }));

WebTransport (HTTP/3 / QUIC)

Use when: modern browser apps where lower latency justifies HTTP/3 infra investment 

Skip when: you need broad browser support today; production without HTTP/3 experience

WebTransport is a Web Transport protocol built on HTTP/3 (QUIC, RFC 9114), which is a UDP protocol that has native connection migration – if you change the network from WiFi to cellular, the connection stays up without re-establishing TCP. WebTransport exposes both unreliable datagrams (like UDP – useful for game state where freshness beats delivery) and reliable ordered streams (like TCP – useful for chat). Early benchmarks from Google and Cloudflare suggest 20-40% latency reduction vs WebSocket in favorable conditions, with the gains coming from QUIC’s zero-RTT reconnection and better congestion handling.

The production readiness caveat is real. Chrome supports WebTransport, Firefox supports it partially, and Safari doesn’t. On the server side, you’ll need an HTTP/3-capable reverse proxy, like Nginx with the QUIC patch, Caddy, or Cloudflare. Also, you may find that the debugging tools are less mature compared to those for TCP.

const transport = new WebTransport('https://api.example.com/chat');
await transport.ready;
const stream = await transport.createBidirectionalStream();
const writer = stream.writable.getWriter();
await writer.write(new TextEncoder().encode('hello'));

Long-Polling (and HTTP/2 Server Push)

Use when: fallback on networks where WebSocket and SSE both fail 

Skip when: as a primary transport in a new build

Long-polling is the pre-WebSocket workaround: the client sends an HTTP request, the server holds it open until it has something to send, then responds. Round-trip latency is 300-800ms in real conditions, and server resource usage is high – you’re holding many open sockets at once. Works on every network on which HTTP works, and that is really its only strong point. HTTP/2 Server Push has been pretty much deprecated by now (Chrome discontinued support in 2022). Do not depend on it.

Long-polling should go in the fallback layer of your transport negotiation protocol – try WebSocket; if not working, try SSE; if not working, try long-polling for the odd network blocking anything else. By 2026, Socket.io is still doing this automatically in case its users are on limited networks.

Server-Side Message Buses: Kafka, NATS, Redis Streams

Use when: fan-out across multiple server nodes, guaranteed ordering, event replay 

Skip when: used as a client-facing transport – browsers can’t connect to Kafka

These aren’t client-facing protocols – they’re the internal bus you pair with whatever client transport you choose. In cases where there are multiple gateways and messages from node A must go to a user on node B, a message bus routes the message. Redis Streams is the easiest if you are already using Redis. NATS is low-latency and simple to operate. Kafka handles high-throughput with durable replay – useful if you need audit trails or replay for a user who was offline during an event.

Production chat architecture in 2026:

• Clients communicate via WebSocket or SSE with gateway nodes
• Gateway nodes send messages to the message bus
• Other gateway nodes listen and push to their respective clients

Transport protocol for the client side and bus choice for the server side are independent decisions. The client-facing transport and the server-side bus are independent choices. This is covered in more depth in the WhatsApp system design teardown – Ejabberd for edge connections, Mnesia for short-term state, and a message routing layer between nodes.

Benchmark Comparison

Real-world results may differ from the numbers you see in the table, as they depend on implementation, server hardware, network conditions, and payload size. For this table, we used public benchmarks and protocol specifications, so consider it only as guidance. 

Resource Cost on Server Side for 1 million Idle Connections: WebSocket costs around 2-4 GB of memory, depending on how the system is implemented, SSE also takes the same resources (around 2 GB), whereas an optimized MQTT Broker such as Mosquitto or EMQX can support 1 million connections on 1 GB only.

Decision Framework

Mistakes When Moving Off WebSocket

These come up consistently in the engineering channels, and post-mortems are worth reading.

Assuming SSE means the client can’t send. It doesn’t. You send from the client to the server with a regular POST or fetch. SSE handles the stream down. For many workflows – LLM streaming, notifications, live dashboards – this POST + SSE-down shape is actually simpler than a bidirectional WebSocket, because your server’s HTTP routing handles the input and you’re not managing connection state for the upstream direction.

Using WebSocket for LLM streaming when SSE is what the upstream API sends. Both the OpenAI API and the Anthropic API stream responses via SSE. If you’re proxying these to a browser, using SSE end-to-end is simpler than converting SSE to WebSocket at your server and then back out to the browser.

Defaulting to QoS 2 on MQTT. QoS 2 is exactly-once delivery, which requires a four-message handshake (PUBLISH → PUBREC → PUBREL → PUBCOMP). It roughly doubles message overhead. Most chat and notification use cases are fine with QoS 1 (at-least-once), which is one ACK, and the application-level deduplication is simpler than the protocol-level overhead of QoS 2.

Using gRPC bidi streaming for browser-facing real-time. gRPC-Web doesn’t support true bidirectional streaming in browsers – it requires a proxy, and the implementation has real constraints. The Connect protocol helps, but if you’re building for browsers, WebSocket or SSE is a cleaner path. gRPC bidi is genuinely strong for backend-to-backend; it’s a mismatch for the browser-facing layer.

Shipping WebRTC DataChannel without TURN. About 15-20% of real connections fail STUN-only NAT traversal. Without TURN, those users get a silent P2P failure. TURN relay costs around $0.05-0.15/GB depending on provider, which is real money at scale – but “doesn’t work for 1 in 5 users” is a worse outcome than paying for relay bandwidth.

Long-polling as a primary transport. It works. It scales poorly. 300-800ms round-trip latency is fine for a fallback; it’s noticeable as the primary channel. Long-poll belongs in the negotiation stack as the last resort, not in the architecture diagram as “simpler than WebSocket.”

Ethora: Transport Layer Already Handled

The decision framework above assumes you’re choosing a transport and building on it. If you’re building a chat or AI product, a chunk of that work is already done. Ethora’s chat SDK with the right transport uses WebSocket for browser real-time by default, long-lived TLS socket connections on native mobile (battery-optimized), and SSE for AI streaming responses – which matches the shape that OpenAI and Anthropic already use, so the chain is SSE from the upstream model, SSE through your Ethora deployment, SSE to the browser. No format conversion at the server layer.

The AI Bots SDK with SSE streaming handles the token-by-token rendering pattern on the client side – the cursor animation, the streaming text append, the citation chips after the answer – so you don’t reimplement that for each deployment. Voice and video calls use WebRTC with a built-in SFU, so you’re not running your own TURN and SFU infrastructure for group calls. REST handles the control plane: history fetches, user management, channel creation. 

If you’re building a messaging solution, Ethora will save you time and budget. If you have any questions left or you’d like to learn how else we can help you, drop us a line.