WebRTC vs Binary WebSocket: Latency Benchmarks
When building zero-install browser remote desktop systems, the conventional wisdom points toward WebRTC. But is UDP peer-to-peer always faster than binary WebSockets coupled with hardware WebCodecs? We ran empirical glass-to-glass benchmarks across symmetric NATs, high-loss packet networks, and corporate enterprise proxies.
The quest for sub-30ms glass-to-glass latency in web-based remote control is governed by two competing transport architectures:
Peer-to-peer transport designed for video conferencing. Uses ICE, STUN, and TURN for NAT punching, with automatic adaptive bitrate and unreliable UDP frame dropping.
Stream-oriented TLS 1.3 transport delivering chunked binary frames into hardware-accelerated WebCodecs VideoDecoder pipelines with zero browser jitter buffer.
1. The Architectural Bottleneck: WebRTC Jitter Buffers
WebRTC is historically celebrated for video streaming because it drops late packets rather than stalling the pipeline on packet retransmission (head-of-line blocking). However, remote desktop environments exhibit a fundamentally different requirement than video conferencing:
- Static Screen Delta Optimization: Unlike human webcam video where 100% of pixels fluctuate constantly, a desktop screen is frequently 95% static. When a user scrolls or moves a mouse, bursty intra-frame changes occur.
- Browser Jitter Buffer Penalty: Chromium's WebRTC implementation enforces a playout delay buffer (typically 20ms to 45ms) to smooth human speech and video pacing. While you can configure
playoutDelayHint = 0, browser rendering engines often smooth frame timing regardless, introducing perceptible mouse pointer latency. - WebCodecs Direct Feed: With Binary WebSockets feeding the W3C
VideoDecoderAPI directly, encoded chunks are pushed straight to anOffscreenCanvasusing WebGL / WebGPU without any intermediate buffering queues.
2. Empirical Benchmark Test Environment
All tests were performed using identical host capture software (Windows 11 Enterprise, RTX 4080, DirectX 11 DXGI Output Duplication) streaming 1920x1080 resolution at 60 FPS to Chromium 124 on a remote client machine over simulated WAN environments via Linux NetEm.
| Metric / Scenario | WebRTC (Direct P2P) | WebRTC (TURN Relay) | Binary WebSocket (SDAgent) |
|---|---|---|---|
| Session Handshake (Time to First Frame) | 820ms – 1,450ms (ICE/STUN) | 1,200ms – 2,100ms | < 140ms (Instant TLS) |
| Glass-to-Glass Latency (15ms RTT LAN) | 32.4ms | 44.8ms | 18.6ms |
| Glass-to-Glass Latency (50ms WAN, 0% Loss) | 68.2ms | 82.1ms | 54.2ms |
| Corporate Firewall Traversal Rate | 62% (Blocks UDP) | 94% (TURN TCP 443) | 99.8% (Standard WSS 443) |
| Host CPU Overhead (Encoding 60 FPS) | 8.4% (libwebrtc stack) | 8.7% | 2.1% (SIMD TurboJPEG) |
| Idle Desktop Bandwidth | 180 – 320 KB/s (Keep-alives) | 220 – 380 KB/s | 38 – 45 KB/s (Delta BBox) |
3. Key Takeaway: Why Enterprise MSPs Prefer Binary WebSockets
Zero ICE Negotiation Failure
In strict banking and healthcare enterprise networks, UDP ports (3478, 19302, 49152-65535) are completely dropped by perimeter firewalls. WebRTC sessions frequently stall for 5–10 seconds attempting ICE candidates before falling back to TURN over TCP 443. WebSockets connect in a single round-trip over standard HTTPS port 443.
Predictable Delta Encoding
Because SDAgent pairs SIMD-accelerated AVX2 TurboJPEG with bounding box delta calculation, only dirty rects (the parts of the screen that changed) are packed into binary buffers. The browser receives small, discrete frames with near-zero decode overhead.
Direct WASAPI Audio Multiplexing
Rather than negotiating separate RTP audio and video tracks that must be synchronized through RTCP sender reports, 48kHz stereo Opus frames are interleaved directly into the binary WebSocket stream, eliminating lip-sync drift.
Experience 60 FPS In-Browser Remote Access
Test SDAgent's proprietary DirectX 11 DXGI + Binary WebSocket pipeline. Zero client software required on the technician side — runs inside Chrome, Edge, Safari, and Firefox.