"Too many DOM Nodes" Replay Issue

[ryan953]

Insert "DOM Node Counts" (Total, added, removed) whenever we send a mutation to the server, and then on the server detect when thresholds are breached in order to create issues. Different sites can have different tolerances, but too many nodes mutated at once indicates memory thrash, render thrash, and slowness especially for people with lower powered devices (mobile, on-batter, older cpu, etc...)

we can describe the problem better, with information like:

your page might look laggy for people because of this. render performance and INP could be affected because it takes a long time to prepare this many nodes… and garbage collector probably kicks in causing more pauses during render.

fixes we can suggest to dev might include:

use virtual scrolling (only render what’s visible)
use on-demand loading & pagination, so not all data needs to be on the browser at once (replay details has this problem :D)
use batched rendering so the browser doesn’t block inputs, and the GC can run on smaller batches

[aliu39]

Where would we get the thresholds from?

[ryan953]

also this:

Similar to the rage click thing, would work best if coupled with other conditions. E.g. only create an issue if we detect this and there is a bad INP value, or an especially slow render span, instead of always creating such a span and telling people it may lead to this

• @mydea

[ryan953]

Where would we get the thresholds from?

We already have mutation limits that the sdk imposes for capture performance reasons, we could re-use those. Alternatively we could measure performance of different scenarios on difference device classes and get some options that people could pick from a dropdown.
What we'd probably do is find some examples of slow perf, and examples of the largest number of mutations, and see if they correlate together. Intuitively 10,000 mutations at a time is too many, 1,000 is interesting, we could start with that and with the idea of correlating with INP we can probably find scenarios where