sentry-javascript: Replay is making my Angular app super slow

I have also been seeing this issue as I’ve been integrating Sentry into our Angular app. I’ve done some digging into it and I believe I’ve found the main cause of the performance hit (at least in our case).

It appears that rrweb is running a call to requestAnimationFrame on a loop (in a method called periodicallyClear), and in Angular requestAnimationFrame is patched so it triggers a change detection whenever it is invoked. This means change detections are happening repeatedly, which slows the app down massively.

I’ve managed to restore the performance of our app by disabling the patching of requestAnimationFrame, and I’ve shared the results below. But ideally the rrweb library should be using the non-patched version of RAF (as well as other patched methods like setTimeout, etc) to avoid unnecessary change detection.

Here’s a screenshot of a profile from our app, when it’s just sitting idly on a simple page for 4 seconds:

And here’s a profile of the exact same page sitting for 4 seconds, but with the requestAnimationFrame NgZone patch disabled:

To those following in the thread: in our newest sdk (version 7.46.0) - we will now add a breadcrumb to the replay when we detect > 1000 mutations. There are also two new experimental options:

• mutationBreadcrumbLimit - changes the count of mutations before creating a new breadcrumb
• mutationLimit - this option will instead take a new full snapshot of the entire DOM instead of processing each individual mutation in the queue. This should improve performance for your users, though you should still look into optimize your code to reduce the amount of DOM mutations!.

In order to use it you’ll have to initialize Replay like so:

new Replay({
  _experiments: {
    mutationBreadcrumbLimit: 500,
    mutationLimit: 1000,
  }
})

Please try it out and let us know how it works for you.

Replay is always going to add overhead to your app

Our angular app has dynamic forms and other complex UI/DOM stuff going on as well.

However, in the past we have used other replay-like products in the past including hotjar, logrocket not to mention a few more. This is the only one that is producing serious performance penalties to our angular app to the point of us having to disable it. So there is some sort of extra inefficiency built into it whether by design or not that is producing this overhead, and until such overhead is brought down to a manageable level we will not be able to use replay going forward.

Thanks for the info! yeah, updating to a more recent version of replay should improve performance a bit. we will work on further improvements down the line too! But it will be great to unblock this angular specific issue here 🙏

I have prepared a repo with a few components, What I found is that it is really difficult to reproduce “super slow” evidence with a demo app.

https://github.com/meriturva/sentry-replay-angular-slower

Here few gifs I have recorded to show that replay makes render slower: Without replay: With replay:

If you need access to a really slow site (when the replay is enabled) I could arrange private access to a staging site where it will be quite easy to show the difference.

Hi @jpike88, I’m sorry that you’re experiencing this performance impact. I understand that this is a serious problem for you and we’re working on improving performance. Our running theory is that the slowdown is caused by a spike in DOM mutations within a very short time period. We’ll soon be able to detect these spikes to confirm our theory. Angular’s default change detection might contribute to this spike, given that it is likely to update DOM elements that necessarily don’t need to be updated.

We’ll keep you posted on further improvements and developments in this area 😃