Skip to main content

Performance & overhead: how Multiplayer stays lightweight

Modern teams are rightly sensitive to anything that could slow users down. Multiplayer is designed to capture useful context without adding noticeable latency or chewing through bandwidth/CPU. This section explains how we do that—and what controls you have.

Design principles​

  • Opt-in by default
    If you’re not recording, there’s zero added runtime overhead. Browser extension off? Widget/SDK not initialized? No impact.

  • Event-based, not video-based
    On the frontend we record structured events (DOM mutations, inputs, clicks, network metadata), not pixel streams. That’s far smaller and cheaper to capture/upload.

  • Correlate by session, not “capture everything”
    We focus on the session you care about and correlate full-stack data around it, instead of hoovering all telemetry across your estate. This is also why we support multiple recording modes: on-demand, continuous, and remote (see more below).

  • Asynchronous, batched I/O
    We buffer and batch uploads in the background, off the critical path. No synchronous calls that block user interactions.

  • Backend-agnostic via OpenTelemetry
    OTel lets you tune what’s instrumented and how much you emit. Think of it like adding structured logging: configurable and minimal when done right.

Recording modes & typical overhead​

Many session replay tools either record every session (expensive, noisy; you end up sampling/filtering constantly), OR provide only on-demand video-style capture (you miss unexpected issues).

Multiplayer offers multiple recording modes, so that it can be adapted to all teams and use cases:

  • On-Demand (manual)
    Nothing runs until a user explicitly starts a recording (browser extension button, widget toggle, or SDK call). Great for “no background footprint” policies.

  • Continuous (rolling buffer)
    Keeps a lightweight rolling window (e.g., ~2 minutes) of events/spans in memory/storage.

    This avoids the heavy cost of recording every session while still catching elusive issues. Read more about our "hybrid" approach to continuous recording in the release notes.

  • Remote/Targeted
    Narrow capture to specific users, tenants, routes, or environments. (coming soon - contact us if you’re interested in early beta).

Overhead by install options​

Multiplayer offers 4 install options, depending on your needs and overhead concerns:

ℹ️ Please contact us for the self-hosted option.

What to expect in practice​

  • No recording = no overhead.
  • On-demand = minimal overhead while active (event capture + async batches).
  • Continuous = lightweight footprint (rolling buffer + async) and automatic saves on exceptions/errors.
  • Backend tracing = comparable to structured logging when instrumented sensibly; the big win is that you get complete session context without turning on “log everything” globally.

Quick checklist before enabling at scale​

  • Limit capture to non-prod first, verify timing/memory with your own RUM/APM.
  • Set masking, ignoreUrls, and network capture rules.
  • In OpenTelemetry, enable batching/memory_limiter; scope enrichments to active sessions.
  • Use continuous recording to auto-save replays with exceptions/errors, limiting the number of on-demand recordings needed to reproduce ellusive, or hard-to-reproduce errors.

Next steps​

👀 If this is the first time you’ve heard about us, you may want to see full stack session recordings in action. You can do that in our free sandbox: sandbox.multiplayer.app

🚀 If you’re ready to trial Multiplayer, the fastest way to get started is to install our browser extension from the Chrome Web Store (Chrome, Firefox, and Edge supported).