Component View on low-end/mobile clients: jank, audio breakup, camera & screen-share failures (not seen on native Zoom client)

Meeting SDK Web
1

Environment

  • @zoom/meetingsdk 6.0.2, Component View (embedded), Next.js web app
  • 1:1 meetings. One participant joins from desktop Chromium; the other frequently from mobile, often low-end (≤4 GB RAM) and/or weak network.

Problem
On low-end / mobile participants with poor connectivity we consistently see: UI jank & freezes, audio degradation/crackle, camera freezing, and the shared screen not rendering on the receiving side. On the native Zoom client, the same devices on the same networks do NOT show these issues — they appear only through the Web Meeting SDK Component View.

Telemetry from production sessions

  • window.crossOriginIsolated === false and SharedArrayBuffer unavailable on a large share of sessions (we serve COOP: same-origin + COEP: credentialless, which is Chromium-only; iOS/WebKit and in-app browsers don’t honor it). On these the SDK runs the single-threaded WASM path.
  • Main-thread longtask blocked ~24% of a 15s window during share on affected devices; seen even on an 8 GB / 8-core device (so not purely hardware).
  • Connection instability on bad networks: up to ~10 connection failures and ~250s join times in a single session.

What we understand so far

  • The Web SDK encodes/decodes via custom WASM instead of native codecs, which is far heavier on low-end devices than the native client.

Questions

  1. What can we do within Component View to reduce these issues on low-end / weak-network clients? Are there init options or quality caps (resolution/FPS limits, disabling gallery/canvas rendering paths, audio-only fallback, etc.) to cut the WASM-codec CPU load?
  2. On browsers where crossOriginIsolated is false (no SAB), what is the recommended path — enable SAB another way, or is running without SAB expected/acceptable for 1:1?
  3. Are the mobile screen-share-not-rendering reports a known issue, and is there a fix or target SDK version?