Very high CPU load, audio/video problems


using your latest web SDK 1.7, we are getting very high CPU loads on our platforms.
This was acceptable on our ‘stronger’ models, but is very bad on our ‘low-end’ model
(nevertheless a 4x core Intel cpu i3-7100U CPU @ 2.40GHz), as video / audio begins stuttering
and/or A/V is out of sync

the zoom application is basically the only application running on the machine, occupying the CPU
most of the time.

if muting VIDEO from the local side (where we see the performnace problems / high cpu load), we receive audio / video in acceptable quality and delay (between audio/video)

suspecting from the WASM section of your API description: preLoadWasm() and also by observing GPU load(which is not changing when starting up zoom JS), we suspect that you do all the en/decoding in JS?

also: using the ‘normal’ browser based webapp in chromium 78 (i.e. the non-JS SDK client), the platform in question delivers sufficient audio/video quality and delay.

  • Is there any possibility to improve this, by e.g. using different webassemblies, restricting resolution, …?
  • are there plans to improve this performance issue in an upcoming JS SDK version?
  • switch to chromium based en/decoding, instead of JS code?


Hey @harald.glanzer,

May I ask what country you are located in, and if you are using the CDN or Local version of the Web SDK?



we are located in austria / europe, and are using the local version 1.7.0.

a colleague of mine, located in north germany, can’t reproduce the problem with the same platform. he reports that his cpu load is much lower, and audio / video quality is ok and in sync.

are you using different encoders / resolutions, depending on the country?


Hey @harald.glanzer, thanks!

Can you send me the meeting id used so I can look into the logs?


for example: 5398465177


Thanks @harald.glanzer,

We are looking into this and will get back to you. (ZOOM-137004)


hello again,

i compared the SDK and the in-browser clients on the platform in question. it turned out
that the in-browser client (i.e. the link ‘join from your browser’) produces much better results than the SDK client:

in browser client:

  • smaller cpu load
  • higher gpu load
  • good AV quality, good A<–>V delay

sdk client:

  • high cpu load (busiest zoom thread needs almost one CPU for its own)
  • nearly unaffected gpu load
  • unacceptable A<–>V delay / video lag


  • is your SDK client using GPU for en/decoding?
  • is there any possibility to use a different video encoder (via setZoomJSLib() call) with different resolution / framerate
  • is it possible to check which resolution / framerate is used for a specific meeting attendee, or globally for the whole meeting?
  • are you aware of such a ‘cpu load’ problem, regarding the SDK client?
  • when will you release your next SDK version 1.8.0, and will there be improvements regarding this problem?
  • are there any news regarding my last request (ZOOM-137004)?

thx in advance,

Hey @harald.glanzer,

We are in the process of looking into (ZOOM-137004).

"The Web SDK enables the development of video applications powered by Zoom’s core framework inside an HTML5 web client through a highly optimized WebAssembly module.

As an extension of the Zoom browser client, this SDK is intended for implementations where the end user has a low-bandwidth environment, is behind a network firewall, or has restrictions on their machine which would prevent them from installing the Zoom Desktop or Mobile Clients."

CC @JackYang, can help answer this one.

Not at this time.

The meeting resolution will have a max of 360p:

“Currently, the Zoom Web SDK encodes at a maximum resolution of 360p. If a user is in a meeting with both native and browser clients, the browser client video displayed within the native client will be of lower quality due to encoding limitations.”

We are not, but we are investigating your issue.

If this is a bug, then yes we will work on fixing it in an upcoming release.


thx for your detailed answer. if i can assist somehow in debugging this issue, please tell me!


1 Like

Hey @harald.glanzer, happy to help!

I’ll let you know if we need additional info!


hi again,

any news here?


Hey @harald.glanzer,

No updates yet. After we look into this, we will get back to you.