Struggling with sharedbufferarray and CORS

Hi :wave:

I have been discussing with the rest of my dev team about potentially replacing our standard webrtc video channel with the zoom SDK.

But, there is one thing we are all very confused by :

  • Zoom needs SharedBufferArray to work performantly and efficiently
  • We load in 3rd party tags from stripe and hubspot etc…
  • There doesn’t seem like there is any fully cross browser way of supporting this (iOS mobile included)

How are people getting around this issue if you are using the zoom SDK in a SPA that loads in code from 3rd party tags where you have no control over the header setup?



Thanks for posting in the Zoom Developer Forum – I am happy to help here! Great question. We highly recommend implementing one of these three options to improve performance for the Web Meeting SDK and Web Video SDK in Chrome and Edge.

The three options are:

  1. Cross-Origin Isolation
  2. Credentialless Headers
  3. Using Chrome’s Origin Trials

To learn more, please see our support guide on how to enable SharedBufferArray below :

Gallery View, Virtual Background, and 720p on web

You also be interested in checking out Google’s on this topic as well:

Load cross-origin resources without CORP headers using

Iframe credentialless: Easily embed iframes in COEP environments

Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

Hi Donte,

Thanks for your reply but unfortunately I don’t think it really helps with my situation as about 50% of our users are on Apple devices.

Solution #1. We can’t do this as we are loading in from 3rd parties we don’t have server access to, e.g Stripe, Hubspot, Intercom

Solution #2. This is not available on safari or Firefox for either mobile or desktop :

Solution #3. This is a beta Chrome program and cannot obviously we cannot rely on this for a production app that is used by 1000s of users every day.

It seems to me that maybe the zoom SDK is not quite production ready unless you can insist your users use chrome on desktop or on an android device - which we cannot.

We have tested in-house and the performance drop without the SharedBufferArray was significant and really loses any advantage that zoom has over regular ‘ol webRTC.

I’d love it if there was an answer I’ve missed somewhere as the performance with the SharedBufferArray was decent!


1 Like

@mrelliot198 Hope you will be fine.

Please dm me I will provide you a better & 100% working solution with no code platforms or either with third-party compatibility & also cross-platform support.

Hi Naeem,

Is your solution zoom based? Because it sounds a lot like you’re spamming the zoom community dev chat to promote your own services?

Or I’m way off and you’ve found a way of credentialess headers on iOS? If so please share.

:point_up_2: please don’t judge the book by its cover. Devs like me are always loyal & very hard-working to provide better solutions.

Seems you are very frustrated. Bye bye

hopeful you will get your solution soon.

Hi, @mrelliot198,

Thank you for your response! I’m going to check with internal folks to find a solution. Please give me a couple of days to back to you as I want to make sure I get you all the details.

1 Like

Hey @mrelliot198

Thanks for your feedback.

Gallery view support on iOS Safari without SharedArrayBuffer is working in progress.
Hopefully, it will be released at the end of July. Please stay tuned.


1 Like


Feel free to ping me for updates on this! I will keep an eye out for Gallery view support on iOS Safari without SharedArrayBuffer and provide an update here when more information is available.

Also, you can follow our changelog for updates as well :

1 Like

Hi Vic,

Thanks for your feedback, to be honest it was not the gallery view so much as the performance that was the main thrust behind our team looking into zoom SDK.

Your own performance report was really impressive, the performance in low bandwidth network conditions and also the lower CPU usage, which we think would be great for mobile devices, especially lower spec ones.

I suppose what’s not really mentioned in the report is how the results change when the SharedArrayBuffer is not accessible when for example the user is using an iPad to join the call?

Does SharedArrayBuffer affect the performance of 1:1 calls (we are a telemedicine company) when not available, or is it mostly required for multi-party calls, as nearly all our calls are 1:1, multi-party is not an issue but performance is a massive issue.

Hoping you can shed some light on this for me, I have tried to research the subject in depth but I’m still not 100% sure what role SharedArrayBuffer plays in the zoom architecture so it’s hard to make the call to go ahead with the switch when I know a significant portion of users wont have the ability to access it.

Thanks so much for your thoughts on the issue, and me and my team would really appreciate any insight you may have - it could save us a tonne of dev work! :grinning:


1 Like

The SharedBufferArray is a high-performance way to transfer video frames between the Zoom SDK and the app. However, it may not be possible to use it if the app is using third-party tags that interfere with the header setup.

One possible solution is to isolate the Zoom SDK in its own iframe or web worker, which would have its own isolated environment for header setup. This would require some additional development effort, but it would allow the app to continue using third-party tags without interfering with the Zoom SDK.

Another option is to use a different approach to video streaming that doesn’t rely on SharedBufferArray. For example, you could use a WebRTC implementation that doesn’t require this feature, or you could use a different video conferencing SDK that doesn’t rely on SharedBufferArray.

Ultimately, the best approach will depend on the specific requirements and constraints of your app. You may need to experiment with different approaches to find the best solution for your particular use case.

Rachel Gomez

Thanks Rachel,

I kind of figured that might be the case but thanks for the confirmation that we weren’t missing anything obvious, we already have a fully working custom webRTC setup but the performance report released by zoom got the dev team talking.

I think for us the best solution would be to isolate the page that contains the video stream, obviously that will take a bit of work, for an SPA that uses a state manager, routing and classes for API abstraction it’s not an insignificant piece of work to split out a whole section of the app into its own mini-app. So I think we’ll hold off for now, but at least I know the way forward if/when we do decide to go for it.

As a side note - I do think that this information should be shared more widely in the zoom docs so devs know what they are getting into and the limitations of using the zoom SDK, our team had basically finished the integration by the time we realised the extent of this issue, and the scale of the fix needed to work around it. Just a little warning box at the top of the docs on domain isolation would have saved our team days of work.

Almost every commercial app in the world is going to have a load of 3rd party tags for all kinds of things, I mean who doesn’t have analytics? It’s not realistic to expect devs to be able to domain isolate an already established web application, many times it will be not even within their control if management use a 3rd party app for reporting or something.

Anyway - thanks for your reply, it did help confirm everything for us.

this does’t work - you need isolation for the outer html AND the inner iframe to enable SharedBufferArray

So really you can only use zoom SDK on an app that doesn’t load any 3rd party tags in, at all.

I understand the reasons behind the header limitations on SharedBufferArray but as I said in my previous comment every commercial SPA loads a bunch of 3rd party tags for all kinds of reasons.

I’m honestly really surprised this doesn’t come up more - I suppose if your just messing about making a test app then you won’t run into this issue but on a commercial SPA this is not viable.

At least webRTC is making decent progress with new media servers and companies now competing on server features like noise reduction etc…

Hey @mrelliot198

Sorry for the late reply.

Enable SharedArrayBuffer will improve the user experience, including reducing the audio latency, supporting gallery view, 720P video, etc.

But in the case of 1:1 calls, the improvement is limited, and the change in CPU and memory usage is small, network is a big fact that impacts the user experience, and that’s what ZOOM Video SDK is good at.


Hi @vic.yang !

Thanks for the clarification, would you say zoom without SharedArrayBuffer is still superior to regular webRTC?

I would love to see a version of zooms SDK comparison report with a version not using the SharedArrayBuffer.

It’s great being able to beat out the competition, but it has to be an apples to apples comparison, and if zooms SDK is used without SharedArrayBuffer in most web apps then I feel like that’s the version that should be tested.

I’m not trying to be awkward with all this, I work for a telehealth company that does hundreds of thousands of sessions a year, and each session needs to work well or the company refunds the client, that’s our policy, if the tech fails (even if it’s because they have poor internet) then we refund, because we feel like that’s the best way to drive adoption of these kinds of technologies.

That’s why it’s so important for us to have reliable data on which technology to use, we currently use 2 different webRTC providers, one is off the shelf and one is on our own servers as a backup.

After seeing the report we started experimenting with zoom SDK (we had looked into it before but mobile browsers weren’t supported till recently).

So, I suppose my question is, do you think we should still look at zoom without using the SharedArrayBuffer (early tests didn’t look great tbh), or…. is there a potential future version of zoom that doesn’t use SharedArrayBuffer?

Can you see a world where zoom is deployed as a webRTC media server, could zoom then use the data layer of webRTC and move its best in class video processing to the server?

1 Like

Hey @mrelliot198

According to the past test reports without SharedArrayBuffer, the latency of audio will be slightly higher than the WebRTC solution, and the video is on par, but the ZOOM solution is better off on a weak network.

We are continuously optimizing the video experience, including the Web RTC layer on the server.


1 Like

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