Our app uses a Web Pixel extension that subscribes to the advanced_dom_changed event. We’ve observed that some third-party apps continuously mutate the DOM at very short intervals, which causes advanced_dom_changed to trigger almost continuously. This can create performance concerns for stores, especially when multiple pixels are listening for the event.
Are there any best practices for handling this scenario, such as throttling or filtering DOM change notifications? Or is Shopify considering platform-level optimizations to reduce the impact of excessive DOM mutations on the advanced_dom_changed event?
advanced_dom_changed is a firehose by design. it fires on any DOM mutation anywhere on the page, so once a few apps are doing their own injections you get hammered through no fault of your own, and since your pixel runs in the strict sandbox you can’t just sidestep it with your own MutationObserver.
so the lever is inside your subscriber. debounce hard, buffer the events and process on a trailing timeout so a burst of 200 mutations collapses into one pass. then filter early using the event payload, bail immediately on mutations that don’t touch the element you actually care about before doing any real work.
the bigger question is whether you need advanced_dom_changed at all. if you’re reacting to something like a cart update or a click, the higher level standard events fire far less often than every mutation. what are you trying to catch when it fires?
I want to detect browser extensions, Actually one of these extension continuously modfied the dom. If I use the event, It cause the browser hang though there is no complex calculation. A single console.log can cause that hang problem because shopify event is always firing.
This is an interesting challenge with advanced_dom_changed. Since the event fires whenever the DOM changes, third-party apps that frequently update elements can generate a high volume of notifications, particularly when multiple Web Pixels are subscribed.
As a best practice, it may help to implement throttling or debouncing within the pixel logic and filter mutations as early as possible so only relevant changes are processed. Limiting expensive DOM queries and maintaining a targeted set of selectors can also help reduce overhead.
I’m also curious whether Shopify has any recommendations for handling high-frequency DOM mutations, or if there are plans for additional filtering, batching, or optimization mechanisms around advanced_dom_changed to help improve performance in these scenarios.