WebRTC vs HLS vs LL-HLS in 2026: Latency, Cost, Scale

Updated October 2026: per-viewer-hour prices for seven delivery options (Cloudflare Stream WebRTC went GA on 15 October), Apple’s 1-second LL-HLS part rule, RFC 8216bis in the RFC Editor queue, and a new WebRTC vs RTMP vs HLS section.

Why Fora Soft wrote this guide

We build video and real-time platforms for a living (250+ projects since 2005), and the WebRTC vs HLS question comes up in almost every scoping call. Worldcast Live, an HD concert platform we built, reaches 10,000 concurrent viewers at 0.4–0.5s glass-to-glass on a custom WebRTC + Kurento stack. Sprii, a Danish live-shopping app we engineered, has moved €365M+ in sales over an RTMP + WebRTC multistreaming pipeline. Ariuum runs WebRTC for real-time debate interactivity. Different answers, same three questions underneath.

This guide reframes the choice. The real answer is rarely “pick one.” It is “know your latency target, your concurrent-viewer ceiling, and your cost tolerance,” then build a hybrid or pick the single protocol that fits. We’ll walk through the benchmarks, the corrected 2026 cost math, the architecture pitfalls, and the decision framework we actually use, the same one we bring to a streaming build.

WebRTC vs HLS in 2026 — the short answer

WebRTC is the browser standard for real-time audio and video: media travels over UDP with 0.2–0.5 seconds of delay, and viewers can talk back. HLS (HTTP Live Streaming) is the HTTP-based protocol that cuts video into small files any CDN can cache; classic HLS plays 15–30 seconds behind live, and Low-Latency HLS (LL-HLS) 2–5 seconds. So the choice is interactivity against reach and cost per viewer.

Choose WebRTC (with a media server like Kurento, mediasoup, or Janus) when you need sub-second latency and a small audience — think interactive gaming, live auctions, real-time trading, or panel debates where speaker-to-speaker latency is the product.

Choose HLS or LL-HLS when you need scale and can tolerate 2–30 seconds of latency: broadcasting to 10K+ concurrent viewers on a budget. Live sports, product launches, education, live-shopping feeds.

Choose the hybrid (WebRTC for speakers + LL-HLS for viewers) when you need both. Speakers get sub-second RTT among themselves; viewers get a stable 2–5s stream with no SFU memory overhead. Most modern live platforms ship this way in 2026. The map below shows where each option actually lives.

Figure 1. Latency against concurrent viewers. Interactive protocols sit bottom-left; cheap, universal protocols sit upper-right; the hybrid buys both.

What latency really means — glass-to-glass vs RTT

You’ll hear “WebRTC is faster” and “HLS has 6-second latency.” Those statements mix three different latency types, and confusing them breaks decisions.

Glass-to-glass (G2G)

The time from a camera capturing something to a viewer seeing it on their screen: capture, encode, ship over the network, decode, render. Measured end-to-end. This is what matters for interactive experiences.

Round-trip time (RTT)

The network round trip between a client and the server, measured in milliseconds. On WebRTC it is typically 50–200ms to the SFU, which is why two speakers can talk naturally: each hears the other with the one-way glass-to-glass delay of 0.2–0.5s. An HLS viewer can’t send anything back in-band — HLS is one-way.

End-to-end (E2E) / streaming latency

How long from a broadcaster speaking to a viewer hearing it. This is what vendors advertise as “LL-HLS has 2-second latency.” Also called perceived or streaming latency. For a one-way broadcast it is the same number as glass-to-glass; it decides whether chat, bets and votes line up with the picture.

Inside WebRTC — how it hits sub-second latency

WebRTC ships raw media packets peer-to-peer or through a Selective Forwarding Unit (SFU, a media relay). No HLS segments, no chunking, no waiting for a segment boundary. Frames arrive, decode, and render immediately. Media is always encrypted hop by hop with DTLS-SRTP; end-to-end encryption needs SFrame on top.

The SFU architecture (the standard for live multi-user)

Each speaker uploads a stream (usually 720p or 1080p at 30fps, 2–5 Mbps). The SFU — mediasoup, Janus, Kurento, or Pion — receives it and forwards the right bitrate to each viewer (simulcast: three layers, for example 1080p, 540p and 270p). Each viewer holds one WebRTC connection to the SFU.

Why it’s fast: packets stream continuously. Codec latency dominates (VP8/H.264 encoding adds ~30–50ms); datacenter-to-client network latency is typically 20–100ms. ICE and DTLS setup (finding the network path and exchanging keys) usually take 0.5–2 seconds upfront, longer through a TURN relay; latency is stable after that.

Why it strains at scale: an SFU has two ceilings, CPU and network. The mediasoup scalability notes put one worker, which runs on one CPU core, at about 500 consumers; a viewer who receives audio and video is two consumers, so plan for roughly 250 viewers per core. The network ceiling usually comes first: 200 viewers at 5 Mbps fill a 1 Gbit port at line rate, so plan for about 150 once packet overhead, retransmissions and headroom are counted. Past that you add servers or cascade, with an origin SFU feeding edge SFUs that re-fan-out. Cascading adds a packet hop of latency and the operational work of linking SFUs.

Inside HLS — how it scales with segment buffering

HTTP Live Streaming (HLS), defined in IETF RFC 8216, chunks a live feed into 2–10 second segments (MPEG-TS or fMP4) and serves them as a playlist. A player reads the playlist, downloads segments in order, buffers 2–3 of them, and plays sequentially. Simple, cacheable, and scalable to millions of viewers on any commodity CDN.

Classic HLS (15–30s latency)

A 6-second segment takes 6 seconds to produce, then the server publishes it plus the playlist. Players start about three segments back from the live edge, so end-to-end latency lands around 18–30 seconds — fine for recorded content or slow-paced broadcasts.

LL-HLS (Low-Latency HLS, 2–5s) — the 2026 standard

LL-HLS is part of HTTP Live Streaming 2nd Edition (draft-pantos-hls-rfc8216bis). Its 22nd revision, dated 1 May 2026, has been in the RFC Editor queue since 15 May 2026, so it is on track to replace RFC 8216; Apple documents the mechanics in its Low-Latency HLS guide. Instead of waiting for a full segment, the packager publishes partial segments (the EXT-X-PART tag), the player asks for the next one through blocking playlist reload and EXT-X-PRELOAD-HINT, and CMAF chunks keep the bytes cacheable on standard CDNs.

How low it goes: Apple’s HLS Authoring Specification requires the part duration to be at least the round-trip time 95% of your viewers see, recommends three times that, names 1 second as the recommended part target, and requires PART-HOLD-BACK of at least three parts. That hold-back is why LL-HLS lands at 2–5 seconds rather than under one.

Why LL-HLS wins in 2026: it works on CDNs that support HTTP/2 and blocking playlist reload (Cloudflare, Akamai, CloudFront, Fastly), needs no SFU fleet, scales to 100K+ viewers, and falls back to classic HLS automatically when a player can’t do partial segments.

Where it stops: it’s still one-way. Viewers can’t send data back in the same stream, so you add a WebSocket or messaging channel for chat and reactions. Smaller parts cut latency but raise request overhead: with 1-second parts each viewer makes about 7,200 requests an hour (one part plus one blocking playlist reload per second), with 0.2-second parts about 36,000.

HLS vs LL-HLS in one paragraph

Both use the same playlists, CDNs and players, and LL-HLS falls back to classic HLS when a player or server lacks the low-latency features. LL-HLS adds partial segments, blocking reload, preload hints and rendition reports, which cut 15–30 seconds to 2–5 seconds. The price is 6× to 30× more HTTP requests and stricter origin and CDN requirements. Tag-by-tag detail is in our LL-HLS deep dive.

Latency benchmarks — what you actually get

These numbers combine our production runs (Worldcast Live, Sprii) with vendor documentation. They assume decent conditions — no Wi-Fi dropout, >5 Mbps available bandwidth.

From our runs: Worldcast Live holds 0.4–0.5s glass-to-glass on a custom WebRTC + Kurento stack (encoder buffer ~100ms + network 150–200ms + player buffer 100–150ms). For Sprii, a live-shopping app, a few seconds of viewer delay is fine; what matters is that product events stay in sync, so they travel on a separate Socket.io channel instead of inside the video. The LL-HLS and DASH rows are typical ranges from vendor documentation, not guarantees: your packager, part size and CDN decide where you land.

WebRTC vs RTMP vs HLS — and how to turn a WebRTC call into HLS

RTMP is an ingest protocol, WebRTC is an interactive transport, and HLS is a playback format, so most production pipelines use two or three of them together. RTMP carries a stream from an encoder such as OBS to your server; browsers stopped playing it when Adobe ended Flash Player on 31 December 2020. WebRTC carries sub-second, two-way media. HLS carries the one-way viewer stream through a CDN. WHIP and WHEP are the standard signalling for pushing media into and pulling it out of WebRTC servers.

How to convert a WebRTC call into an HLS or RTMP stream

Take the call off the SFU, mix it into one program, encode once and package once. Speakers stay at 0.2–0.5 seconds and the audience watches the LL-HLS output at 2–5 seconds:

• Tap the tracks. mediasoup exposes them through a PlainTransport as plain RTP, Janus through RTP forwarders, and LiveKit through its Egress service.
• Compose. Pick one layout (grid or active speaker) and one audio mix, in a headless browser or a GStreamer or FFmpeg pipeline.
• Encode and package. Encode one H.264/AAC program, then write fMP4 LL-HLS parts to an origin or push RTMP to YouTube, Twitch or a CDN ingest. FFmpeg 8.0 (August 2025) also ships a WHIP muxer, so the same tool can push back into WebRTC.
• Deliver. A CDN fans the HLS out; chat, reactions and bids ride a WebSocket channel next to the video.

Our lesson on the WebRTC-to-HLS recording bridge walks through the pipeline step by step, and the WHIP ingest guide covers the WebRTC side of ingest.

Cost per viewer at scale — where the math lives

At October 2026 list prices, one 1080p viewer-hour costs about $0.011 on a budget CDN, $0.06 on Cloudflare Stream, $0.18–0.19 on AWS CloudFront pay-as-you-go and $0.24–0.54 on per-minute WebRTC APIs. The delivery vendor moves the bill about 50×; the protocol name moves it far less. Here is where those numbers come from.

HLS and LL-HLS: you pay per GB, and per request on hyperscalers

A 1080p stream at 5 Mbps moves 2.25 GB per viewer-hour (5 Mbit/s × 3,600 s ÷ 8 ÷ 1,000). AWS CloudFront gives the first 1 TB a month free, then charges $0.085/GB for the next 9 TB and $0.080/GB for the next 40 TB in the US and Europe, reaching $0.020/GB only above 5 PB, plus $0.01 per 10,000 HTTPS requests (October 2026). Bunny CDN charges $0.01/GB on its standard network in Europe and North America and $0.005/GB on its volume network for the first 500 TB. Hetzner dedicated servers with a 1 Gbit port have unmetered traffic, and extra traffic elsewhere costs €1 ($1.20) per TB.

LL-HLS adds a request bill. With 1-second parts a viewer makes about 7,200 requests an hour, against about 1,200 for classic HLS with 6-second segments and 36,000 with 0.2-second parts. On CloudFront that is $1.20, $7.20 and $36 per 1,000 viewer-hours. CloudFront’s flat-rate plans, from $15 a month per distribution up to $1,000 for the Premium level with 50 TB, cap both lines; we work through that math in our edge streaming cost guide.

WebRTC: fixed servers or a per-minute API

Self-hosted. An SFU server is a fixed monthly cost, so its price per viewer-hour depends on how busy you keep it. Size it by the network first: at 5 Mbps a 1 Gbit port carries about 200 viewers at line rate (plan for ~150), at 2.5 Mbps (720p) about 300–400, and unlike HLS you can’t hand the fan-out to a cache.

Managed. At October 2026 list prices Daily charges $0.004 per participant-minute ($0.24 per viewer-hour), Agora $3.99 per 1,000 minutes for HD and $8.99 for Full HD ($0.24–0.54), and LiveKit Cloud on its Scale plan $0.0004 per minute plus $0.10/GB ($0.25 at 1080p). The outlier is Cloudflare Stream: WebRTC playback over WHEP became generally available with billing from 15 October 2026 at the same $1 per 1,000 minutes delivered as its HLS, or $0.06 per viewer-hour. WebRTC broadcasts on Stream can’t be recorded yet.

Worked example: 10,000 viewers for one hour

10,000 viewers × 2.25 GB = 22.5 TB, or 600,000 viewer-minutes. List prices, October 2026, with the event as the month’s only traffic:

Two caveats. The CDN rows are egress only: you still run an encoder, packager and origin, while Cloudflare Stream includes encoding. And the table assumes every viewer pulls 5 Mbps; with an adaptive ladder the average is lower, so real egress is lower too.

Reach and device support — browser, TV, low-end Android

WebRTC. Needs a WebRTC-capable browser: Chrome, Firefox, Safari 11+, Edge. Not Opera Mini, not old Android browsers, and not most smart TVs. If you must support Roku, Apple TV, or Xbox, you need HLS as a fallback. Adaptive bitrate lives in your application code, not the protocol.

HLS. Plays everywhere: Safari (iOS/macOS native), Chrome/Firefox via hls.js or Shaka, Android native, Roku, Apple TV, even feature phones. It ships a built-in adaptive bitrate ladder (1080p / 720p / 360p / 144p) and the client picks the best fit. Desktop Chrome and Edge 142 and later also play .m3u8 natively since late 2025, but production web players still ship hls.js or Shaka for ABR control, DRM and LL-HLS tuning.

LL-HLS. Native on Safari 14+ (iOS 14+, announced at WWDC 2019, shipped in 2020), needs hls.js or Shaka elsewhere. On smart TVs it depends on each platform’s player and SDK (Apple TV plays it natively), so test every target device and keep a classic-HLS fallback for 100% coverage.

Comparison matrix — every dimension at a glance

The hybrid pattern — WebRTC speakers plus LL-HLS viewers

This is the architecture that won in 2026. You run a WebRTC SFU for a small speaker group (5–50 people). A compositor taps the speakers’ tracks from the SFU and mixes one program, an encoder packages it as LL-HLS, and viewers pull that stream from a CDN. Speakers get sub-second RTT among themselves; viewers get a stable, buffered stream without touching the SFU. Our scalable video streaming team ships this split on mediasoup, LiveKit or Wowza, with ABR and multi-CDN fan-out on the viewer side.

Figure 2. The hybrid live pattern: a WebRTC SFU handles speakers in real time, then one master feed is encoded to LL-HLS and fanned out over a CDN to the mass audience.

Why it works

Speakers enjoy sub-1s RTT (WebRTC). Viewers get stable, buffered video (LL-HLS) without overwhelming the SFU. The SFU runs on a single node or a small cluster, and the encode-to-segment pipeline is independent of viewer count, so scaling the audience never touches the real-time tier.

Implementation checklist

• A compositor taps the speaker tracks over plain RTP (mediasoup PlainTransport, Janus RTP forwarders) or LiveKit Egress and mixes one program.
• Encoder encodes the composited program to H.264/AAC and packages it as LL-HLS with 2–4s segments and parts of 0.33–1s (Apple recommends 1s, and at least three times your P95 round-trip time).
• Segments land in object storage or a local origin; a CDN (Cloudflare, Fastly, CloudFront, Bunny) fans them out.
• The playlist updates on every part (every 0.33–1s) via blocking reload.
• Fall back to classic HLS automatically when a player can’t do partial segments.

WebRTC architecture pitfalls at scale

1. The SFU CPU wall. A single node saturates once you push past a few hundred concurrent forwards at higher bitrates. Beyond that you cascade SFUs over persistent server-to-server links, and each hop adds 20–50ms. Simulcast helps: each speaker sends multiple bitrate variants, the SFU forwards only what each viewer needs, and you push the practical ceiling toward what the hardware allows: about 250 viewers per CPU core and 150–200 per 1 Gbit port at 1080p.

2. ICE failures on restrictive networks. Corporate firewalls, symmetric NATs and blocked UDP make some ICE negotiations fail or fall back to a TURN relay, which adds a hop of latency. Run TURN over TCP and TLS on port 443, and measure ICE success and relay share from day one instead of trusting a rule-of-thumb percentage.

3. Bandwidth swings on cellular. A speaker on LTE can drop from 5 Mbps to 1 Mbps mid-sentence; the encoder can’t keep up and viewers see stutter. Encode simulcast at 2–3 tiers (5 / 2 / 0.5 Mbps) upfront so viewers can drop down cleanly.

4. SFU memory adds up. A forwarding SFU is far lighter than a transcoding MCU, but jitter buffers, ICE and DTLS state still cost memory per connection. Measure RAM per connection in a load test and size nodes from that number. Cascade in a tree and accept the latency cost, or offload viewers to LL-HLS entirely (the hybrid).

5. Codec mismatches. Chrome prefers VP8, Safari prefers H.264. A pure SFU forwards rather than transcodes, so the clean fix is to pin codecs per client and run separate paths. If you instead bridge them with a transcoding gateway in front of the SFU, budget the extra CPU and the 20–50ms it adds per hop. A little planning, no surprises.

HLS architecture pitfalls — segment sizing and CDN cache

1. Segment size is a latency/throughput trade. Smaller segments cut latency but multiply HTTP requests; larger ones lock latency to 15–30s. LL-HLS typically runs 2–4s segments with 0.33–1s parts (Apple’s example uses 0.33s parts; its authoring spec recommends 1s). On congested cellular, a short part can arrive late and cause rebuffering — measure before you commit.

2. Cold CDN cache at stream start. A brand-new stream has nothing at the edge, so the first requests hit the origin and add 200–500ms each. Pre-warm the CDN ~30 seconds before going live by pushing the first segments to edge nodes.

3. ABR ladder tuning is empirical. A 5–8 tier ladder (1080p@5 Mbps down to 240p@300 kbps) only works if it matches your audience’s real bandwidth distribution. Run a week of analytics, measure bitrate versus rebuffer rate, and trim tiers that don’t earn their place.

4. Playlist staleness in live. The playlist updates every segment; update it too aggressively without caching headers and you hammer the origin. Set a short Cache-Control on the playlist so edges serve it briefly and re-fetch at the live edge.

5. Recording means tapping the origin, not the CDN. You can’t reliably pull segments back from the CDN — the origin may garbage-collect them first. Archive segments at the origin/encoder as they’re created, or record the source feed directly for VOD.

Code and config — LL-HLS output and a WebRTC join

LL-HLS segment generation (FFmpeg)

This takes an RTMP input (from your compositor or encoder) and writes short-segment fMP4 HLS, the base an LL-HLS packager builds on:

ffmpeg -i rtmp://localhost/live/main \
  -c:v libx264 -preset veryfast -b:v 5M -maxrate 5.5M -bufsize 11M \
  -g 30 -keyint_min 30 -sc_threshold 0 \
  -c:a aac -b:a 128k \
  -f hls \
  -hls_time 1 \
  -hls_list_size 6 \
  -hls_flags delete_segments+independent_segments \
  -hls_segment_type fmp4 \
  /var/www/html/live/stream.m3u8

Key flags: -hls_time 1 gives 1-second segments, and -g 30 -sc_threshold 0 forces a keyframe every second at 30 fps so the muxer can actually cut there; -hls_segment_type fmp4 gives you fMP4 (CMAF-compatible) segments, the usual container for LL-HLS; independent_segments keeps each segment random-access and CDN-friendly. For true LL-HLS parts (EXT-X-PART, blocking playlist reload) you also need an origin or packager that implements the Low-Latency server profile from RFC 8216bis Appendix B.

WebRTC join flow (mediasoup / Node.js)

// Client joins a mediasoup room
const device = new mediasoupClient.Device();
await device.load({ routerRtpCapabilities });

const transportParams = await fetch('/api/transport', {
  method: 'POST',
  body: JSON.stringify({ rtpCapabilities: device.rtpCapabilities })
}).then(r => r.json());

const transport = device.createSendTransport(transportParams);

// transport.on('connect') and transport.on('produce') signalling handlers
// must be registered here, or produce() never resolves (omitted for brevity)
const producer = await transport.produce({
  track: videoTrack,
  encodings: [{ maxBitrate: 500000 }, { maxBitrate: 1500000 }, { maxBitrate: 4500000 }],
  codecOptions: { videoGoogleStartBitrate: 1000 }
});

The client requests a send transport (connects to the SFU), adds a camera or screen track, and becomes a producer. The SFU then forwards simulcast layers to each subscriber.

Mini case: Worldcast Live — 10,000 HD viewers at 0.4s

Situation. A concert platform wanted to stream live HD to 10,000 concurrent viewers worldwide, with the audience seeing a performer react within half a second. Textbook wisdom says “WebRTC can’t scale past a few hundred” — but classic HLS at 15–30s would have killed the interactivity.

The architecture. We built a custom WebRTC stack on the Kurento media server, hosted on AWS, with multichannel audio (five channels), production-grade HD bitrates, and dynamic quality adjustment for poor connections. Full-duplex two-way streaming lets performers in different cities play together in real time, and a white-label Multiple Venue Streaming plugin syncs the feed across multiple sites at once.

Outcome. 0.4–0.5s glass-to-glass at 10,000 concurrent viewers, scaled across media-server nodes — among the first platforms to hit sub-second at that scale. The lesson is the honest one: the “500-viewer wall” is an engineering budget, not a hard protocol law. With the right media server, encoders, and adaptive logic, pure WebRTC scales further than the rule of thumb suggests. It just costs more than letting a CDN carry passive viewers.

Mini case: Sprii — live shopping at €365M+ scale

Situation. A Danish live-shopping platform needed to run flash-sale broadcasts where viewers tap “buy” within seconds of a host announcing a deal. Latency of 2–5 seconds was fine; reliability, reach, and product-sync were not negotiable.

The architecture. We built Sprii on an RTMP + WebRTC multistreaming pipeline with FFmpeg, fanning the same broadcast out to Cloudflare, Mux, and custom web stores plus Facebook and Instagram — each with independent overlay configs. Product events (IDs, quantities, discount codes) ride a separate Socket.io channel, decoupled from the video so overlays and gamification stay in sync without touching the stream. Origin runs on Hetzner.

Outcome. The platform has moved €365M+ in cumulative sales across 72,000+ live events for 3,000+ brands. According to Sprii’s platform data, live-shopping viewers watch for ~20 minutes versus 54 seconds on static pages, driving up to 20× higher conversion. The pattern — CDN-delivered video plus a real-time data channel for commerce events, became a template we reused for other live-commerce builds.

Cost model — three tiers, real 2026 numbers

Here is what delivery costs for a live event at October 2026 list prices, per 1,000 viewer-hours, at 1080p and 5 Mbps (2.25 GB per viewer-hour). The chart makes the punchline obvious: the delivery vendor moves the bill more than the protocol does.

Figure 3. Delivery cost per 1,000 viewer-hours (1080p at 5 Mbps, vendor list prices, October 2026). Per-GB CDNs are cheapest; Cloudflare Stream prices WebRTC and HLS the same; per-minute WebRTC APIs cost 20–50× a budget CDN.

Tier 1: ~1,000 concurrent

• LL-HLS, budget CDN: ~$11–23 per event-hour. Cheapest and simplest.
• Cloudflare Stream: $60, and the same price buys sub-second WebRTC playback.
• LL-HLS, AWS CloudFront: ~$190 at the $0.085/GB rate, or about $106 if the free 1 TB and 10M requests apply to this event.
• WebRTC, self-hosted: five to seven 1 Gbit servers at 1080p, or three to four at 720p, as a fixed monthly cost. Viable if you need sub-1s or two-way.

Tier 2: ~10,000 concurrent

• LL-HLS, budget CDN: ~$113–225 per event-hour.
• Cloudflare Stream (HLS or WebRTC): $600.
• LL-HLS, AWS CloudFront: ~$1,830 including requests.
• Managed WebRTC APIs: $2,400–5,400.
• Hybrid (WebRTC speakers + LL-HLS viewers): the sweet spot — one or two SFU servers and one compositor/packager for the stage, plus the CDN line above for the crowd.

Tier 3: ~100,000 concurrent

• Pure self-hosted WebRTC: not practical — roughly 500–670 servers at 1080p in a cascade.
• LL-HLS, budget CDN: 225 TB per hour, ~$1,125 on Bunny’s volume network. The default, optionally with a small WebRTC speaker group.
• Cloudflare Stream: $6,000 per event-hour, if sub-second for everyone is worth 5× the CDN bill.

A decision framework — five questions

Answer these top to bottom; the first “yes” usually points at your build. The tree below is the same logic in one glance.

Figure 4. A five-step decision path: latency and device needs route you to WebRTC, classic HLS, the hybrid, or LL-HLS as the default.

1. What’s your concurrent-viewer ceiling? Up to a few hundred, WebRTC alone is viable. From hundreds to 10K, the hybrid usually wins. Past 10K, LL-HLS for the audience is the cheapest path, with or without a WebRTC stage; past 100K, plan for multi-CDN.

2. What’s your latency target? Under 1s, WebRTC only. 2–5s, LL-HLS (1–2s only with LL-DASH or tightly tuned short parts). 5s+, classic HLS. Unsure? Default to 2–5s (LL-HLS is the safe bet).

3. Do viewers send data back in the same stream? Yes (auction bids, game controls) → WebRTC, or WebRTC plus a messaging channel. No (watch-only, chat is separate) → LL-HLS is fine.

4. What device coverage do you need? Smart TVs, Roku, old Android → HLS is the only universal option. Web plus mobile → LL-HLS works.

5. What will delivery cost at your scale? Multiply expected viewer-hours by the per-viewer-hour price in the cost table: $0.011–0.19 for CDN-delivered HLS, $0.06 for Cloudflare Stream (HLS or WebRTC), $0.24–0.54 for managed WebRTC APIs (October 2026 list prices). Self-hosted SFUs are a fixed monthly cost instead.

If the answers point at a hybrid or a multi-region SFU, our custom WebRTC architecture team designs the topology, picks the media server and sizes nodes against your viewer curve before code ships.

Five pitfalls — what breaks in production

1. Underestimating ICE failure. Plan for a share of WebRTC connections to fail or fall back to a TURN relay, size TURN for the relayed share you measure in a pilot, and test on real cellular and corporate networks, not just Wi-Fi.

2. Choosing segment size without testing. A 1s part is Apple’s recommended default, but on congested cellular even a short part can arrive late and rebuffer. Measure rebuffer rate at 0.33s, 0.5s and 1s parts before you commit.

3. Compositor CPU in hybrid setups. Mixing speakers means decoding every incoming track and encoding the program again. Budget that decode and encode CPU per program, and make sure the compositor can decode every codec your speakers send (VP8 and H.264).

4. Not instrumenting rebuffer rate and RTT. Target rebuffer rate under 1% and median segment fetch under 200ms. If you don’t measure them, you learn about breakage from angry users.

5. Insufficient TURN capacity. If TURN runs out, new ICE negotiations fail and you lose viewers. Load-test at 2× expected concurrency and confirm ICE success stays above 98% with TURN over TLS on port 443 before launch.

KPIs — what to measure in production

Quality KPIs. Rebuffer ratio (sessions with a stall) — target <1%. Startup latency (play() to first frame) — target <3s LL-HLS, <5s HLS. Weighted average bitrate — target >70% of viewers at 720p+.

Business KPIs. Concurrent peak viewers, engagement (session duration ÷ broadcast duration), mid-stream churn (target <5% for live events), and revenue per viewer where it applies.

Reliability KPIs (WebRTC). ICE success rate (target >98% with TURN over TLS 443), mid-call drop rate (target <5%), SFU CPU (target <70% for headroom), and TURN relay share (watch the trend against your pilot baseline).

When NOT to use WebRTC or HLS

If your content is pre-recorded with random-access scrubbing (rewind, fast-forward), neither WebRTC nor live HLS is the right first choice. Use a progressive MP4 or a VOD platform tuned for seeking.

If you need content protection or compliance (HIPAA medical consults, say), plan it explicitly. HLS gets DRM (Widevine, FairPlay, PlayReady). WebRTC’s DTLS-SRTP encrypts every hop, but the SFU decrypts the media, so true end-to-end encryption needs SFrame or encoded transforms on top. HIPAA asks for encryption in transit plus a business associate agreement with every vendor that touches the media; a bare CDN won’t satisfy the audit.

And if you have fewer than 50 viewers and can tolerate 15–30s latency, a simple RTMP ingest that repackages to HLS (Nginx-RTMP, or a managed one) behind a basic CDN is cheaper and simpler than either. You don’t need the sophistication; you need the invoice to stay small.

FAQ

Is WebRTC faster than HLS?

For latency, yes: WebRTC delivers 0.2–0.5s glass-to-glass; HLS is 2–30s depending on the variant. But faster isn’t automatically better. HLS is cheaper per viewer, scales further, and reaches more devices. If you don’t need sub-second latency, LL-HLS usually wins on simplicity.

Can WebRTC and HLS run in the same app?

Yes, and that’s the hybrid pattern: WebRTC for speakers or interactive users, LL-HLS for the watching audience. Speakers get sub-1s RTT; viewers get a stable, buffered stream. Most modern live platforms run this as their default architecture.

What is LL-HLS, and how is it different from classic HLS?

Low-Latency HLS, defined in RFC 8216bis (draft-22 is in the RFC Editor queue since May 2026) and Apple’s HLS Authoring Specification, adds partial segments (0.33–1s parts; Apple recommends 1s) and blocking playlist reload to cut latency from 15–30s to 2–5s. It runs on standard CDNs and falls back to classic HLS automatically. It is the live protocol of choice in 2026.

Does WebRTC or HLS use more client CPU?

WebRTC generally costs the client more CPU: it decodes a live real-time stream, runs jitter buffers, echo cancellation, and congestion control continuously. HLS players decode pre-segmented media with more buffering slack, so they’re lighter, especially on low-end mobile browsers and smart TVs where hardware HLS decoding is common. On battery-constrained devices, HLS is the gentler option.

Does HLS work everywhere?

Classic HLS plays on essentially every device: iOS, Android, web, smart TV, Roku. LL-HLS is native on iOS 14+ and Safari 14+ (announced at WWDC 2019, shipped in 2020), needs hls.js on other browsers, and varies by smart-TV platform in 2026. For 100% coverage, keep a classic-HLS fallback and test against your real audience.

What about WebTransport and Media over QUIC for streaming?

WebTransport now ships in every major browser: Safari added it in 26.4 in March 2026, joining Chrome, Edge and Firefox. Media over QUIC (MoQ) is still an IETF draft (draft-ietf-moq-transport-22, 1 October 2026) and Cloudflare’s MoQ relays are in beta. For production in 2026, use WebRTC or LL-HLS and prototype MoQ beside them.

Is WebRTC suitable for 100,000 concurrent viewers?

Not on self-hosted SFUs alone: at about 150–200 viewers per 1 Gbit server at 1080p, 100,000 viewers means roughly 500–670 servers in a cascade. Managed WebRTC delivery changes that: Cloudflare Stream’s WebRTC playback went GA on 15 October 2026 at $1 per 1,000 minutes. For most teams the hybrid is still simpler: WebRTC for speakers, LL-HLS for the crowd.

Is HLS encrypted end-to-end?

HLS segments are encrypted in transit (TLS to the CDN) but not end-to-end by default. For true broadcaster-to-viewer protection you add DRM (Widevine, FairPlay, PlayReady) or AES-128 segment encryption. WebRTC encrypts every hop with mandatory DTLS-SRTP, but an SFU decrypts the media to forward it; end-to-end protection needs SFrame or encoded transforms.

What about latency-sensitive sports betting?

Betting needs the video and the odds feed close together in time, which rules out classic HLS at 15–30s. Use WebRTC (under 0.5s) or tightly tuned LL-HLS (2–5s) with the event feed on WebSocket or gRPC, and get legal review, because rules differ by jurisdiction.

LL-HLS vs WebRTC: which one fits my app?

Use LL-HLS when 2–5 seconds is acceptable and you need many viewers on any CDN at $0.011–0.19 per viewer-hour; use WebRTC when you need under 0.5 seconds or two-way media, on your own SFUs or a $0.06–0.54 per viewer-hour service (October 2026 list prices). Many platforms run both: WebRTC on stage, LL-HLS for the audience.

Is WebRTC better than RTMP?

For playback, yes: browsers stopped playing RTMP when Flash ended in December 2020, while WebRTC plays in every modern browser at 0.2–0.5s. For ingest, RTMP is still the most widely supported encoder output, and WHIP (RFC 9725, March 2025) is its WebRTC-based replacement when you need sub-second ingest.

How do I convert WebRTC to HLS?

Pull the tracks off the SFU (mediasoup PlainTransport, Janus RTP forwarding or LiveKit Egress), composite them into one H.264/AAC program, and package that program as LL-HLS on an origin behind a CDN. Speakers stay at 0.2–0.5s; viewers get 2–5s. To reach YouTube, Twitch or a CDN ingest instead, push the same program over RTMP.

How much does it cost to stream to 10,000 viewers for an hour?

At 1080p and 5 Mbps the hour moves 22.5 TB: about $113–225 on Bunny CDN, $600 on Cloudflare Stream, about $1,830 on CloudFront pay-as-you-go including requests and $2,400–5,400 on per-minute WebRTC APIs (October 2026 list prices).

What to read next

Ready to choose your protocol and scale it?

WebRTC and HLS aren’t rivals in 2026; they’re complements. WebRTC owns interactive, sub-second latency for small groups; HLS and LL-HLS own scale and device reach. The hybrid (WebRTC speakers, LL-HLS viewers) is the default for modern live platforms because it balances latency, cost, and operational sanity. Worldcast Live proved WebRTC can scale to 10K when engineered well; Sprii proved a CDN-delivered multistream with a separate real-time data channel can carry €365M+ in live commerce.

The path is simple: a few hundred viewers with sub-1s latency, WebRTC. Hundreds to 100K with 2–5s acceptable for the audience, hybrid or pure LL-HLS. 100K+ or every-device coverage, LL-HLS for the audience. Most platforms land on the hybrid because they want both interactivity and scale.

The engineering (SFU ops, segment lifecycle, CDN cache, codec tuning, ICE fallback) is real but well-trodden. We’ve shipped this stack for concert streaming, live shopping, debate platforms, and trading. The cost model is predictable once you use real CDN numbers. The latency targets are achievable.