Video latency: optimize real-time WebRTC
Short answer
Video latency in WebRTC is the delay between emitting a frame and receiving it on the other side. Under normal conditions, expect 200 ms to 1 second for interaction — well below deferred streaming (HLS, 5–30 s). Main factors: distance to SFU, network quality, ICE path choice, and server sizing.
WebRTC latency vs deferred streaming
| Protocol | Typical latency | Use case |
|---|---|---|
| WebRTC | 200 ms – 3 s | Dialogue, real-time video, support |
| WebSocket (data) | 50 – 500 ms | Signaling, chat |
| HLS / DASH | 5 – 30 s | Mass webinar, replay |
For real-time communication, WebRTC is the right protocol.
Six latency factors in WebRTC
1. Network distance to SFU
Every millisecond of RTT adds up. An SFU in France minimizes latency for European participants.
2. ICE path (direct vs TURN)
- Direct: minimal latency;
- TURN relay: added latency (1 server hop);
- TURN TCP fallback: higher than UDP.
3. Codecs and encoding
Hardware-accelerated VP8/VP9/H.264 reduces latency. 720p/30fps is a good latency/quality trade-off.
4. SFU sizing
A saturated SFU adds jitter and buffering.
5. Client network quality
Poor Wi-Fi or 4G triggers bitrate adaptation and variable latency.
6. Architecture (SFU vs MCU)
SFU forwarding without transcoding has lower latency than MCU mixing.
Acceptable latency by use case
| Use case | Target latency | Protocol |
|---|---|---|
| Conversation / real-time video | < 300 ms ideal | WebRTC |
| Support / diagnosis | < 1 s | WebRTC |
| 10+ participant meeting | < 1–2 s | WebRTC + SFU |
| Interactive live (Q&A) | < 3 s | WebRTC or hybrid |
| Mass webinar (passive) | 5–30 s acceptable | HLS/DASH |
Typical WebRTC latency values
| Scenario | Typical end-to-end latency | Notes |
|---|---|---|
| Same LAN, direct ICE | 150–200 ms | Optimal lab conditions |
| Same country, SFU in-region | 200–400 ms | Standard B2B production |
| TURN relay (same region) | +20–100 ms | One server hop |
| Cross-border EU session | 300–800 ms | Distance + routing |
| Corporate VPN + TURN | 400 ms – 1 s | Common support scenario |
| Saturated SFU node | 1–3 s+ | Capacity issue, not protocol |
These ranges help interpret webrtc typical latency benchmarks and guide webrtc latency optimization (SFU placement, simulcast, TURN documentation).
How to measure latency
- getStats() API: RTT, jitter, packet loss on the client;
- Server monitoring: SFU latency, CPU load;
- Network tests: firewall workstations, 4G, Wi-Fi in pilot;
- MOS score: perceived audio/video quality.
Latency and scalability
Scalability must not degrade latency: that is why horizontal SFU (not MCU) is the standard. When participant count grows, add SFU nodes rather than mixing streams — see SFU WebRTC infrastructure for sizing guidance.
IT optimization checklist
- SFU hosted close to participants (France);
- TURN documented with UDP priority, TCP fallback;
- SFU sized for participant count;
- Hardware-accelerated codecs enabled;
- Simulcast / SVC for adaptation without retranscoding;
- Continuous monitoring (jitter alerts > 30 ms).
How does Leagora optimize latency?
WebRTC infrastructure with SFU in France, documented TURN, simulcast, monitoring. Contact for a network workshop.
Products: meeting.leagora.io, assistance-video.fr.
FAQ
What minimum latency with WebRTC?
~150–200 ms in optimal direct conditions. In B2B production: 300 ms – 1 s is realistic.
Does TURN increase latency?
Yes, by one server hop (~20–100 ms). Less than connection failure without TURN.
Does latency depend on browser?
Marginally: recent Chrome, Firefox, Safari are comparable. Network dominates.
Does leagora.io guarantee latency figures?
leagora.io documents factors. SLA guarantees are contractual.
Key takeaways
- WebRTC production latency = 200 ms – 1 s (sub-second in optimal conditions).
- France SFU + documented TURN + simulcast = optimization triad.