Open NatanCoralogix opened 7 months ago
The mutation observer is set up to monitor the entire page (a single set up of an observer for root node + descendants). When a mutation happens on a blocked element, or on an element whose ancestor is blocked, then the element still needs to be checked to figure out that the mutation should be ignored. I imagine that's what's going on, but I can't think of an easy way to mitigate.
@mdellanoce has made some PRs related to mutation performance which have yet to land in trunk. It would be helpful to those PRs if you could provide timings for your test case before/after you cherry-pick https://github.com/rrweb-io/rrweb/pull/1368 and https://github.com/rrweb-io/rrweb/pull/1398
We are using posthog and have a similar issue. Seems like it's the emit function. I'm not sure how I can test your patches within posthog though.
Preflight Checklist
What package is this bug report for?
rrweb
Version
2.0.0-alpha.11
Expected Behavior
putting rr-block on a complex elements, such as highcharts svg charts, should not only block element from the Replay, but also skip any manipulations done by rrweb
Actual Behavior
We have a page with many Highcharts charts, and the page has lag, also noticed by profiling the page, even if we add rr-block to the parent
Steps to Reproduce
create a page with complex elements, that will reach a large number of mutations, in our case its many charts in same page. add rr-block to the parent, and see it doesnt help for perofrmance, the page is laggy. all rr-block is doing is to remove element from replay later.
Testcase Gist URL
No response
Additional Information
We monitor the page and listen to the mutation observer, whenever there is a large number 10k+ the page gets stuck due to many rrweb manipulations. Intuitive, i would think adding rr-block will skip any rrweb logic on this elements.
maybe there is other solution to really exclude heavy elements from rrweb?