How do you think about performance overhead with regards to Session Replay?

[jas-kas]

When we launched Session Replay at Sentry, a concern that would come up time and again is the performance overhead of our client SDK and how that might impact the experience end-users have on our customers’ applications. We understand the importance of this concern and as such the Session Replay SDK takes several measures to avoid negatively impacting the performance of the application on which it’s running, detailed here.

For most web applications, the performance overhead of our Session Replay SDK is imperceptible to end-users. To provide confidence and transparency in this area, we're developing a new tool aimed at quantifying the performance overhead of the Session Replay SDK on your application without deploying anything to production. Some example metrics we’re thinking about are CPU, memory, network/bandwidth, and core web vitals (LCP, FID, CLS).

The goal is to give you a better understanding of its impact, so you can feel comfortable installing Replay. To ensure this tool is as useful as possible, we need your input. We're interested in understanding:

1. What are the key metrics you'd prioritize when evaluating the performance overhead of the Session Replay SDK?
2. Are there any specific use-cases you think we should consider when developing this tool?

Your feedback is essential to us. We aim to tailor this tool to your needs, ensuring it provides actionable insights. Please comment your thoughts below!

[sandstrom]

When Sentry enabled[1] is set to false (dev, for example), and Sentry Replay is setup like this:

let sentryReplay = new Sentry.Replay();

Sentry.init({
  enabled: false,
  dsn: '…',

  integrations: [
    sentryReplay,
  ],
});

Is there still a performance hit? (i.e. is Sentry Replay still running in the background)

[1] https://docs.sentry.io/platforms/javascript/configuration/options/#enabled