Performance of MutationObserver to detect nodes in entire DOM

Question

I'm interested in using MutationObserver to detect if a certain HTML element is added anywhere in an HTML page. For example's sake, I'll say that I want to detect if any <li>'s are added anywhere in the DOM.

All the MutationObserver examples I've seen so far only detect if a node is added to a particular container. For example:

some HTML

<body>

  ...

  <ul id='my-list'></ul>

  ...

</body>

MutationObserver definition

var container = document.querySelector('ul#my-list');

var observer = new MutationObserver(function(mutations){
  // Do something here
});

observer.observe(container, {
  childList: true,
  attributes: true,
  characterData: true,
  subtree: true,
  attributeOldValue: true,
  characterDataOldValue: true
});

So in this example, the MutationObserver is setup to watch a very certain container (ul#my-list) to see if any <li>'s are appended to it.

Is it a problem if I wanted to be less specific, and watch for <li>'s over the entire HTML body like this:

var container = document.querySelector('body');

I know it works in the basic examples I've setup for myself... But is it not advised to do this? Is this going to result in poor performance? And if so, how would I detect and measure that performance issue?

I figured maybe there was a reason that all the MutationObserver examples are so specific with their targeted container... but I'm not sure.

Performance issues are specific to a given scenario. If your entire document only has a few simple elements I'm certain you won't have any issues. If you fear having performance issues, profile! — Amit, Jul 27 '15 at 17:37
I have used plenty of `MutationObserver`s and had them recursively watch the entire DOM. I've personally never had a problem with performance. — Luke, Jul 27 '15 at 17:44
The primary reason for the introduction of MutationObservers and the deprecation of MutationEvents is because MutationObservers are much faster because they aggregate changes together. We also use MutationObservers with `subtree: true` on large documents and it has never been an issue. — loganfsmyth, Jul 27 '15 at 18:09
Why are you observing changes in attributes and character data? You say so yourself -- you want to observe possible additions of `li` elements? If something is a candidate for sub-optimal performance, I'd say asking for more events than you need, is that. — Armen Michaeli, Apr 26 '19 at 18:52
As an example, Boomerang.js (https://github.com/akamai/boomerang), the web performance monitoring lib, is using a `MutationObserver` on the whole document to measure SPAs page load time. — JulienD, Feb 13 '20 at 09:08

wOxxOm · Accepted Answer · 2022-03-10T01:38:36.170

This answer primarily applies to big and complex pages.

If attached before page load/render, an unoptimized MutationObserver callback can add a few seconds to page load time (say, 5 sec to 7 sec) if the page is big and complex (1, 2). The callback is executed as a microtask that blocks further processing of DOM and can be fired hundreds or a thousand of times per second on a complex page. Most of the examples and existing libraries don't account for such scenarios and offer good-looking, easy to use, but potentially slow JS code.

Always use the devtools profiler and try to make your observer callback consume less than 1% of overall CPU time consumed during page load.
Avoid triggerring forced synchronous layout by accessing offsetTop and similar properties
Avoid using complex DOM frameworks/libraries like jQuery, prefer native DOM stuff
When observing attributes, use attributeFilter: ['attr1', 'attr2'] option in .observe().
Whenever possible observe direct parents nonrecursively (subtree: false).
For example, it makes sense to wait for the parent element by observing document recursively, disconnect the observer on success, attach a new nonrecursive one on this container element.
When waiting for just one element with an id attribute, use the insanely fast getElementById instead of enumerating the mutations array (it may have thousands of entries): example.
In case the desired element is relatively rare on the page (e.g. iframe or object) use the live HTMLCollection returned by getElementsByTagName and getElementsByClassName and recheck them all instead of enumerating the mutations if it has more than 100 elements, for example.
Avoid using querySelector and especially the extremely slow querySelectorAll.
If querySelectorAll is absolutely unavoidable inside MutationObserver callback, first perform a querySelector check, and if successful, proceed with querySelectorAll. On the average such combo will be a lot faster.
If targeting pre-2018 Chrome/ium, don't use the built-in Array methods like forEach, filter, etc. that require callbacks because in Chrome's V8 these functions have always been expensive to invoke compared to the classic for (var i=0 ....) loop (10-100 times slower), and MutationObserver callback may report thousands of nodes on complex modern pages.

The alternative functional enumeration backed by lodash or similar fast library is okay even in older browsers.
As of 2018 Chrome/ium is inlining the standard array built-in methods.

If targeting pre-2019 browsers, don't use the slow ES2015 loops like for (let v of something) inside MutationObserver callback unless you transpile so that the resultant code runs as fast as the classic for loop.
If the goal is to alter how page looks and you have a reliable and fast method of telling that elements being added are outside of the visible portion of the page, disconnect the observer and schedule an entire page rechecking&reprocessing via setTimeout(fn, 0): it will be executed when the initial burst of parsing/layouting activity is finished and the engine can "breathe" which could take even a second. Then you can inconspicuously process the page in chunks using requestAnimationFrame, for example.
If processing is complex and/or takes a lot of time, it may lead to very long paint frames, unresponsiveness/jank, so in this case you can use debounce or a similar technique e.g. accumulate mutations in an outer array and schedule a run via setTimeout / requestIdleCallback / requestAnimationFrame:
```
const queue = [];
const mo = new MutationObserver(mutations => {
  if (!queue.length) requestAnimationFrame(process);
  queue.push(mutations);
});
function process() {
  for (const mutations of queue) {
    // ..........
  }
  queue.length = 0;
}
```
Note that requestAnimationFrame fires only when the page is (or becomes) visible.

Back to the question:

watch a very certain container ul#my-list to see if any <li> are appended to it.

Since li is a direct child, and we look for added nodes, the only option needed is childList: true (see advice #2 above).

new MutationObserver(function(mutations, observer) {
    // Do something here

    // Stop observing if needed:
    observer.disconnect();
}).observe(document.querySelector('ul#my-list'), {childList: true});

Apparently I can't award a bounty immediately but I'm giving this answer a 50 point bounty because I find the live DOM collection trick for watching rare elements clever! Good answer! — Benjamin Gruenbaum, Apr 26 '19 at 18:48
Also, you might want to update the list - for example `for... of` is as fast as a regular for loop now in V8 :] — Benjamin Gruenbaum, Apr 26 '19 at 18:49
Yes, it's finally slower by just 10% or even less in recent versions of Chrome. — wOxxOm, Apr 26 '19 at 18:53
There was an intermediate stage where it was converted to a regular loop (with a counter) but apparently it was replaced to its own IR instruction in https://github.com/v8/v8/commit/06ee127b75726f9ee541aab10f6aecfe4d96675a - pretty cool stuff! In any case, for...of vs for shouldn't matter much here (worth mentioning that this optimization is for arrays - so the advice still holds some merit for NodeLists) — Benjamin Gruenbaum, Apr 26 '19 at 19:14
What's the point of debouncing the mutation observer? I thought it already does that natively by collecting mutations in an array and then calling the callback only once. See also [this new question](https://stackoverflow.com/q/65554806/1048572) — Bergi, Jan 03 '21 at 21:10
@Bergi, it's for the case when processing is complex and takes a lot of time. MutationObserver runs in a microtask queue so multiple callbacks may still reside in one task, which can lead to very long paint frames and jank. — wOxxOm, Jan 03 '21 at 23:06
@wOxxOm I am figuring this stuff out, but I just noticed that when I register an observer for a parent object first and then proceed to register another one later for a child, I do not get the events on the child. This has led me to believe that my best strategy is simply to register one on body or higher if possible and then detect the desired element and trigger my own event/listener myself. however, I wonder if this is really the best. I am confused why I am unable to observe a child if a parent is already observed. Since either childList or characterData has to be true I see no simple ... — mjs, Oct 03 '21 at 15:14
@mmm, some sites may swap the entire container with the new rendered element high up in the tree so indeed you won't be able to use this optimization in such cases. If you want to discuss this further, please open a new question with an [MCVE](/help/mcve). — wOxxOm, Oct 03 '21 at 15:31
@wOxxOm Here is a question: https://stackoverflow.com/questions/69426920/javascript-mutationobserver-observing-a-child-element-after-observing-a-parent — mjs, Oct 03 '21 at 16:44
This is an incredible explanation. You should follow your 5th point in your final answer, however :) `document.getElementById('my-list')` instead of `document.querySelector('ul#my-list')` — jfudman, Oct 28 '21 at 14:40
@jfudman, this answer is about the callback of the observer because it may (theoretically) run thousands of times. Finding the parent in this example is a one-time deal so there's no need to optimize it unless someone observes hundreds of different parents creating hundreds of observers. — wOxxOm, Oct 31 '21 at 09:08
How can this be the accepted answer as the question specifically states that he does _not_ want to observer a specific element but rather be _less specific_ and observe the whole body element? — Nicolai Ehemann, Jun 01 '22 at 07:28
`const mo = new MutationObserver(async mutations => { // ... });` is also a good approach to avoid DOM changing during mutation observer callback. — Chester Fung, Jun 28 '23 at 07:12

Performance of MutationObserver to detect nodes in entire DOM

1 Answers1

This answer primarily applies to big and complex pages.

Back to the question:

Linked