Skip to main content

Performance & overhead

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 of how Multiplayer stays lightweight​

  • 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 conditional (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.

  • Conditional
    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 with your own app, you can follow the Multiplayer configuration steps. You can start a free plan at any time: go.multiplayer.app

📌 If you have any questions shoot us an email or join us on Discord! 💜