Zoom Meeting Web SDK and RAM / CPU usage

Testing implementation of Zoom Meeting Web SDK, we noticed a high usage of RAM (also CPU), but I would like to focus on RAM numbers.

Browser Console Error

Which Web Meeting SDK version?

Meeting SDK Code Snippets

To Reproduce(If applicable)
Simple joining a meeting via Zoom Web SDK using prepareWebSDK


Device (please complete the following information):

  • Device: MS Surface
  • OS: Windows latest
  • Browser: Edge

Additional context
CPU @ 40%, RAM from Edge @ 2GB

In comparison, Apple MacBook Pro mid 2015 with Catalina → CPU @ 80%, RAM from Edge @ 1.6GB

Hey @camillo,

Thank you for reaching out to the Zoom Developer Forum. Just to confirm, did this happen when using the Sample Web App? If so, please make sure that you’ve also followed our guide on Improving Web SDK Performance.

Just to make sure that I understand, you’re seeing the following statistics when using the Web SDK on Windows with the Edge browser:

CPU @ 40%, RAM from Edge @ 2GB

And see the following statistics when using MacOS;

CPU @ 80%, RAM from Edge @ 1.6GB

Is that correct?


I think @camillo is comparing an implementation with the Web SDK to the Zoom native client on MacOS.

  • Zoom native clients + Native SDK can use CPU/GPU (but if i’m not wrong Zoom only use CPU, at least for the SDKs) and therefore rely on both CPU/GPU and RAM.
  • Zoom web SDK is browser base technology and therefore cannot really access the same to the CPU. Yes you have worker threads but that’s all and not all browser support it. Because of that, the web SDK rely more on the RAM than the CPU and cannot rely on the GPU neither.

So yes, with the Web SDK, there are more requirement on the RAM, and by experience, the more participant in a meeting you join with the Web SDK and the more RAM it will consume (to handle multiple data fluxes in Memory)
With any native SDK/client, memory should be much more stable, but you’ll also see CPU/GPU consumption for computing & rendering tasks.

Thanks @MaxM for reaching out. We already followed all the steps in the Improving Web SDK Performance; Web SDK 1.9.9 is already implemented and functioning in our Laravel App; however, while testing it, we have noticed lots of buffering issues on video and audio receiving - quickly we went to check CPU and RAM consumption in various machines, and as a matter of fact, it was quite high even with “everything else shut off”,

As a second test, since we were afraid that this performance issue was related to our faulty implementation, we run similar tests on Sample App, and Zoom browser client - which means an environment just within Zoom world. Sadly, we experienced exactly the same performance issues: video participants freezing, audio not in sync (same network), RAM/CPU under stress. In this case, Zoom Web SDK in Sample App I believe was in v. 2.0.1

That brought us to the conclusion that the bottle-neck was not lying in our app, but rather on the Zoom infrastructure, leaving the implementation completely unusable.

However, we went one step further testing Zoom Browser Meeting not in https://us02web.zoom.us/ but in the EU counterpart, thinking that it could improve the performance https://eu02web.zoom.eu/ …at the beginning, it seemed fine, but soon after we got again deterioration of video and audio - again this was a test outside our environment.

@nvivot Thanks for your input here!

@camillo I really appreciate the detail provided and the amount of testing that was performed. This definitely sounds like a back-end issue. From here, I’ll just need a meeting ID and I can engage our engineering team to see if they are able to identify any causes on the back-end.

Would you be able to create a ticket with that information through our Developer Support Center and also add a link to this thread?

I’ll follow up with you there.


Thanks @MaxM …ticket issued to Developer Support Center. Looking forward to a follow up.

Thank you for the update, @camillo! We will continue to look into this issue there.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.