Realtime Transport Selection Playbook (SSE vs WebSocket vs WebTransport)

Date: 2026-03-12
Category: knowledge
Scope: Choosing and operating browser↔server realtime transport with clear reliability, latency, and operability trade-offs.

1) Why this matters

Many teams pick a realtime protocol by habit:

• “Realtime = WebSocket”
• “Simple notifications = SSE”
• “Future-proof = WebTransport”

That shortcut causes expensive rewrites.

Transport choice affects:

• failure behavior during network churn,
• buffering/backpressure risk,
• infra compatibility (CDN/LB/proxy),
• complexity of reconnect + resume semantics,
• long-term portability across browsers.

2) Quick decision map

Use this as a default starting point:

Pick SSE when

• traffic is mostly server -> client (alerts, timeline, progress, market snapshots),
• you want HTTP-native simplicity,
• message rate is moderate,
• auto-reconnect + Last-Event-ID replay fits your model.

Pick WebSocket when

• you need bidirectional low-latency messaging,
• broad production compatibility is required today,
• you can actively manage flow control and buffering.

Pick WebTransport when

• you need multiple logical streams and/or datagrams,
• some data can be unreliable or out-of-order,
• you control modern browser/server stack and can absorb higher implementation complexity.

3) Protocol-level mental model

SSE

• One long-lived HTTP response (text/event-stream).
• Built-in event framing (event, data, id, retry).
• Browser reconnection behavior is native.
• Excellent for “append-only push feed” patterns.

WebSocket

• Full-duplex persistent channel after HTTP upgrade.
• Widely supported and battle-tested.
• App must design framing, ordering policy, replay, and flow safety.

WebTransport

• HTTP/3/QUIC-based session with:
  • bidirectional streams,
  • unidirectional streams,
  • datagrams.
• Lets you separate reliability classes (critical vs best-effort paths) in one session.

4) Non-obvious constraints teams miss

4.1 WebSocket backpressure is your problem

MDN explicitly notes classic WebSocket API does not provide automatic backpressure. If consumer speed < producer speed, memory/CPU pain follows unless you add app-level controls.

Practical guardrails:

• enforce per-client outbound queue caps,
• drop or coalesce stale updates (especially market ticks/cursor positions),
• expose bufferedAmount telemetry and shed load early.

4.2 SSE over HTTP/1.1 has tab-scaling pain

MDN documents the well-known low per-origin connection limits under HTTP/1.1 (commonly ~6), which makes multi-tab usage painful. Under HTTP/2, stream multiplexing substantially improves this.

Rule of thumb: if you adopt SSE for browser apps, ensure HTTP/2 (or better) end-to-end at the serving edge.

4.3 WebTransport is powerful but still portability-sensitive

WebTransport gives better transport primitives, but support and operational maturity vary by client/server path. Treat it as a deliberate platform decision, not a drop-in WebSocket replacement.

5) Reliability semantics by product use case

A) Portfolio/dashboard updates

• Best fit: SSE (or WebSocket if bidirectional controls are needed)
• Why: monotonic updates + easy reconnect/replay with event IDs

B) Chat / collaborative editing

• Best fit: WebSocket
• Why: symmetric send/receive, broad compatibility
• Must add: ack/retry/idempotency and bounded queues

C) Fast multiplayer / telemetry mix (critical + lossy)

• Best fit: WebTransport
• Why: reliable streams for state sync + datagrams for ephemeral signals

D) Mobile flaky network with strict battery/cost goals

• Prefer minimizing chattiness regardless of protocol:
  • delta/coalesced updates,
  • adaptive heartbeat,
  • resumable session tokens.

6) Production architecture patterns

Pattern 1: Control/Data split

• Reliable control plane: auth refresh, subscription changes, sequence checkpoints
• Bulk/ephemeral data plane: ticks, presence, cursor, telemetry bursts

Do not mix all message classes into one undifferentiated queue.

Pattern 2: Resume-first protocol contract

On reconnect, client sends:

• last committed sequence/event ID,
• session/user identity,
• capability hints (protocol/version/features).

Server returns:

• replay window result (replayed / gap-too-old),
• fresh watermark sequence,
• optional forced resync instruction.

Pattern 3: Degrade ladder

1. WebTransport (if supported and healthy)
2. WebSocket
3. SSE
4. Long-poll fallback (last resort)

Feature-detect + policy-gate instead of hardcoding one transport forever.

7) SLO-focused observability checklist

Track by transport and client cohort:

• connect success rate / handshake latency,
• reconnect frequency and mean recovery time,
• replay success vs replay-miss rate,
• outbound queue depth / drops / coalesced count,
• p95/p99 message e2e latency,
• session churn around deploys and edge incidents.

Alert on symptoms, not just disconnect count:

• rising buffered queues,
• replay-miss spikes,
• repeated reconnect loops in a specific ASN/region/browser.

8) Safe rollout strategy

1. Ship unified message envelope first (seq, type, timestamp, idempotency key).
2. Add transport abstraction + parity tests.
3. Run shadow transport in canary cohort.
4. Compare SLO deltas (latency, drops, replay misses, CPU/memory).
5. Promote gradually by browser/region.
6. Keep one-click rollback to previous transport policy.

9) Practical defaults (if you must choose today)

• Default web app realtime: WebSocket + strict queue limits + resume protocol.
• Simple server-push feed: SSE over HTTP/2 with event IDs and replay buffer.
• Advanced mixed reliability workload: WebTransport only when platform ownership is strong and fallback paths are tested.

10) References

• MDN: Using server-sent events
  https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

• MDN: WebSocket
  https://developer.mozilla.org/en-US/docs/Web/API/WebSocket

• MDN: WebSocketStream
  https://developer.mozilla.org/en-US/docs/Web/API/WebSocketStream

• MDN: WebTransport
  https://developer.mozilla.org/en-US/docs/Web/API/WebTransport

• WHATWG WebSockets Standard
  https://websockets.spec.whatwg.org/

• IETF draft: WebTransport over HTTP/3
  https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/

One-line takeaway

Choose transport by reliability semantics and failure behavior first, not by hype: SSE for simple server-push, WebSocket for broadly compatible duplex realtime, WebTransport for advanced mixed-reliability workloads with deliberate platform ownership.