When your CPU is killing your WebRTC calls #performance #webrtc

12 Feb 2026 · 1 min

Watch on YouTube

1:23

In this short technical monologue, Tsahi Levent-Levi explains that the usual WebRTC quality metrics—jitter, packet loss, and latency—are insufficient for diagnosing call problems because they miss the underlying device resource constraints. He argues that many call quality issues stem from insufficient CPU or memory on the client device, which manifest as jittery audio, lost packets, and dropped frames, yet are not directly reported by standard metrics. Levent-Levi introduces RTCstats as a solution: it aggregates observations from various WebRTC statistics to infer hidden problems such as CPU overload, allowing engineers to quickly identify the true root cause and avoid wasted time troubleshooting the network. He ends with a rhetorical question prompting viewers to recall times they mis‑debugged network issues that were actually CPU‑related.

Chapters

We usually look at jitter, packet loss, and latency when we want to understand the behavior and user experience for our users in WebRTC. But if you do only that, you're actually missing a lot of context and information. You know that something is wrong, maybe, but you won't even know what the root cause is. Often the problem isn't in the network, it's actually in the device. There is not enough memory or CPU. You'll see that by having jittery experience, there are packets that get lost, dropped frames, but you won't know that the reason is actually the CPU. To understand that, you need to glean that information from different components in WebRTC because there is no metric that tells you that the CPU is struggling and it's overloaded. With RTCstats, we actually have observations that solve that problem. It looks for these hints around the WebRTC metrics and statistics and then gets to the observation of what went wrong. And if the issue is the CPU, you'll know that immediately, so you won't waste time struggling with understanding what the problem is. I've got a question for you. Have you ever been in a position where you try to debug issues with the network only to find a few hours later that the problem was actually in the CPU of the user?