Well balanced CPU and network use in WebRTC

29 Jan 2026 · 1 min

Watch on YouTube

1:20

In this presentation, the speaker discusses the inherent tension between CPU usage and network bandwidth in WebRTC applications. Pushing high compression reduces bandwidth but spikes CPU load, while using low‑complexity codecs saves CPU but inflates bandwidth consumption. The proposed solution is a continuous, dynamic negotiation process that monitors real‑time metrics—such as round‑trip time, jitter, encode time, and CPU load—to adjust both bandwidth allocation and encoder complexity on the fly. The goal is to achieve a stable, balanced system rather than maximizing a single performance metric. The talk concludes by inviting the audience to share the metrics they use to verify a balanced load in their own WebRTC deployments.

Chapters

In CPU, performance is often viewed as a tug of war between CPU and the network. You optimize for one and the other screams for attention. Now, we're not here to eliminate the bottlenecks. We're here to balance the system that we have. The ultimate goal for a robust universal service is going to be balancing the CPU and the network use at the same time. If you push too high on compression to save on bandwidth, You spike the CPU, not good. If you rely too heavily on low complexity codecs to save on CPU, the bandwidth goes up the roof, not good. Now the solution is a continuous dynamic negotiation and that means using metrics like round trip time and jitter, which we use to inform bandwidth decisions, but also using encode time and CPU load to inform your encoder complexity decisions. This is the art of WebRTC optimization, ensuring that neither resource is consistently overloaded, not the CPU and not the network. Aim for stability, not maximum throughput on a single metric. If you want to balance your WebRTC application, you know where to find me. And I leave you with a question: what metrics do you use to check that your WebRTC application is currently running in a balanced load?