CPU use is as dynamic as network (if not more)

25 Jan 2026 · 2 min

Watch on YouTube

1:31

In this short commentary, Tsahi Levent-Levi warns developers that treating the client‑side CPU as a static resource is a critical mistake, especially for WebRTC media optimization. He explains that a user’s CPU load can swing dramatically within seconds due to new tabs, OS or software updates, and background processes that are invisible to the application. While browsers handle the local video encoder, they have little control over the decoding of incoming video streams that arrive from SFU media servers or other peers. Consequently, developers must proactively factor client‑CPU fluctuations into the bandwidth‑allocation logic of their SFUs; otherwise, CPU starvation can cripple the application. He ends by asking viewers to consider the biggest challenge they face when trying to predict and measure sudden client‑CPU drops.

Chapters

Developers mistakenly treat client CPU as a static resource. This can't be farther from the truth, and this is also a critical error that you might be making. The fact is, in WebRTC client media optimizations, the CPU is as dynamic as the network, if not more. Think about it. A user opens a new CPU tab. It might get software update or an operating system update or just something else that is running on his device in, you know, jobs or processes that he is not even aware of. His CPU load can plummet to 90%, plunge to 20%, all in the course of a couple of seconds. While the browser takes care of the local video encoder, it can't do a lot about the incoming video that it is decoded. Why? That's because it gets fed that video from other resources from your SFU media servers or other users. He can probably ask him to reduce bitrates, but he's not going to do that oftentimes, especially not in a media server environment. And this is something that you need to manage on your own. Otherwise, this starvation is going to kill your application. You're always a developer to factor in the client-side CPU in the bandwidth allocation of your SFU. Here's a question for you. What is the biggest challenge that you face when you try to predict and measure the sudden drops in available CPU on the client?