SSE vs WebTransport

Part of SSE vs WebSockets vs HTTP Polling, under SSE Protocol Fundamentals & Architecture.

WebTransport is the newest browser transport: a session over HTTP/3 (QUIC) that offers many independent bidirectional and unidirectional streams plus unreliable datagrams, from a single connection. It solves problems Server-Sent Events never tried to solve — low-latency unreliable delivery, many independent flows without head-of-line blocking, binary data in both directions. It also asks much more of the infrastructure. This guide compares the two for the workloads where the choice actually comes up.

Symptom & Developer Intent

Teams usually consider WebTransport when:

  • A real-time feature needs lower latency than a TCP stream can give under packet loss, such as game state or live cursors on poor networks.
  • A single SSE stream multiplexes many independent feeds, and a stall in one delays all of them.
  • Binary data needs to flow both ways at high rate.
  • The team wonders whether SSE is “legacy” now that WebTransport exists.

The intent is to pick the transport that fits the workload and the infrastructure you actually have, not the newest one.

Root Cause Analysis

The two transports differ at every layer below the application:

SSE and WebTransport side by side Matrix comparing SSE and WebTransport across direction, framing, reliability, independent streams, infrastructure and browser support. SSE and WebTransport side by side Property SSE WebTransport Direction server to client both ways Data UTF-8 text binary Unreliable datagrams no yes Independent streams via HTTP/2 or 3 native, many Works through any HTTP proxy yes needs HTTP/3 path Auto-reconnect + resume built in application code Server support any HTTP server HTTP/3 stacks only strength neutral weakness
WebTransport wins on capability; SSE wins on reach, simplicity and compatibility with the HTTP infrastructure you already run.

Head-of-line blocking. SSE over HTTP/1.1 or HTTP/2 runs on TCP: one lost packet stalls every byte behind it until it is retransmitted. Over HTTP/3, each HTTP stream is independent at the transport level, so an SSE stream on HTTP/3 is not blocked by other streams on the same connection — but its own bytes are still delivered in order. WebTransport adds datagrams, which are never retransmitted, and many streams per session, each independent.

Infrastructure. SSE is ordinary HTTP. Every proxy, CDN, load balancer and WAF handles it, with the configuration covered elsewhere on this site. WebTransport requires UDP to reach an HTTP/3 server end to end, a server stack that implements WebTransport, and load balancers that route QUIC connections correctly. Corporate networks that block UDP force a fallback.

Semantics. SSE gives you event framing, ids, automatic reconnect and resume. WebTransport gives you raw streams and datagrams; reconnection, framing and resumption are yours to build.

Step-by-Step Resolution

Step 1 — Classify the traffic

Choosing between SSE and WebTransport Decision tree for choosing SSE or WebTransport based on whether the data may be lost, whether the client sends high-rate data, and whether the infrastructure supports HTTP/3 end to end. Choosing between SSE and WebTransport Is stale data worse than lost data? WebTransport datagrams yes no Heavy binary upstream from clients? WebTransport streams yes no Plain server-to-client feed? SSE yes no SSE, revisit later
Most server-to-client feeds end at the second question. WebTransport earns its complexity when loss is acceptable or the upstream is heavy.

Server-to-client feeds that must arrive intact — notifications, dashboards, logs, AI responses — are SSE’s home ground. Traffic where the latest value supersedes older ones and a late packet is worse than a lost one — positions in a game, cursor coordinates at high rates, sensor telemetry for display — is where datagrams shine.

Step 2 — Use SSE over HTTP/3 before reaching for WebTransport

If the concern is head-of-line blocking between several feeds, serve SSE over HTTP/3 and give each feed its own stream. Each SSE request becomes an independent QUIC stream; loss on one does not stall the others. This keeps EventSource, reconnect and resume, and needs only HTTP/3 support at the edge. SSE over HTTP/3 and QUIC trade-offs covers what changes.

Step 3 — If you adopt WebTransport, keep an HTTP fallback 

async function connectRealtime(url) {
  if ('WebTransport' in window) {
    try {
      const wt = new WebTransport(url);
      await Promise.race([wt.ready, timeout(3000)]);     // UDP may be blocked: fail fast
      return wrapWebTransport(wt);
    } catch { /* fall through */ }
  }
  return wrapEventSource(new EventSource(url.replace('/wt/', '/sse/')));   // same events, HTTP path
}

Present both transports behind one interface, so the application code does not care which one is active. Build resumption into the WebTransport path yourself — it has no Last-Event-ID.

Step 4 — Use both where each is strongest

A common split in interactive products: WebTransport datagrams for high-rate, loss-tolerant state (positions, cursors), and SSE for everything that must arrive (chat messages, notifications, document operations). The SSE stream also acts as the control channel that survives when UDP is blocked.

p99 update latency at 2 % packet loss Bar chart comparing p99 latency of position updates under two percent packet loss for SSE over HTTP/2, SSE over HTTP/3, and WebTransport datagrams. p99 update latency at 2 % packet loss SSE over HTTP/2 (TCP) ~420 ms SSE over HTTP/3 ~260 ms WebTransport datagrams ~95 ms p99 milliseconds, 20 updates per second, 80 ms RTT
Illustrative lab figures. TCP's head-of-line blocking dominates the tail at loss; HTTP/3 removes cross-stream blocking; datagrams remove retransmission waits entirely.

Step 5 — Account for the operational cost before committing

WebTransport changes operations more than code. Load balancers must route QUIC by connection ID rather than by client address, because QUIC connections survive address changes; firewalls and security groups must allow UDP on 443; observability tools built around HTTP request logs see a session, not the events inside it; and capacity planning must account for per-session state in the server stack. None of that is a reason to avoid WebTransport where it is the right tool, but it is a real cost, and it applies to every environment — staging, production, regional failover — not just to the code.

SSE’s costs, by contrast, are the ones every HTTP service already pays: proxy configuration, timeouts and connection limits. For a team shipping a notification feed or an AI response stream, that difference usually settles the question in SSE’s favour, and HTTP/3 gives SSE most of the transport-level improvement with none of the new operational surface.

Validation & Monitoring

Measure on the networks your users have, not in the office. Record, per session, which transport was established, how long establishment took, and how often WebTransport failed over to the HTTP path. A high fallback rate in a region usually means UDP is filtered there, and the WebTransport investment is not reaching those users.

performance.mark('rt-connected', { detail: { transport: rt.kind, ms: rt.connectMs } });

Browser support for WebTransport has grown steadily but arrived at different times across engines; check current support for your audience before depending on it, and keep the fallback regardless.

Production Checklist

Frequently Asked Questions

Will WebTransport replace SSE?

Unlikely for most feeds. SSE works through all existing HTTP infrastructure with built-in reconnection; WebTransport adds capabilities that most server-to-client feeds do not need.

Does SSE over HTTP/3 get the benefits of QUIC?

It gets independent streams, faster connection setup and connection migration. It does not get unreliable delivery; SSE bytes are always delivered in order.

What happens to WebTransport on networks that block UDP?

The session cannot be established. Clients must detect this quickly and fall back to an HTTP-based transport such as SSE or WebSockets.

Can WebTransport and SSE share a server?

Yes, if the server stack supports both. They can publish from the same event bus, with the transport chosen per client.