DOM mutation events were introduced to HTML several years ago in order to allow web applications to monitor changes to the DOM by other scripts. Unfortunately, adding listeners for any of these events to a document has a highly deleterious effect on performance, an effect which is not mitigated in the slightest by later removing those listeners. For this reason, it is best to avoid using mutation listeners at all costs, especially from extensions. This document lays out some alternatives which do not have such severe performance impacts.

Non-mutation triggers

It is usually possible to tell when a mutation has occured or is about to occur without resorting to mutation events or observers. Most of these methods are specific to a particular site or codebase.

hashchange and popstate events

Most AJAX-heavy sites update the URL when they significantly change their content, either via a change to the fragment identifier (hash) or more recently via the history.pushState method. The former triggers a hashchange event while the latter triggers a popstate event. Event listeners for those events are the preferred method for detecting DOM modifications when feasible.

Often times, this must be used in combination with a slight delay, or even polling, via setTimeout, for cases where the URL change happens before the page is fully loaded.

This method works particularly well with services like Google Instant, and the Gawker family of sites.

Monkey patching

In many instances, especially when dealing with chrome code, the best way to modify actions which result in DOM mutations is by wrapping the functions that trigger those changes. For instance, when you want to modify the result of DOM mutations that you know are the result of the doAwesomeDOMStuff() function, you can wrap it as follows:

Now, whenever doAwesomeDOMStuff() is called, the original function will be called, followed by your own doAwesomerDOMStuff() function, which can then further modify the DOM as needed. Variations on this method include modifying the arguments passed to the wrapped function, modifying its return value, and making changes both before and after the original method is called. This scheme is highly flexible and can be made to work under most circumstances.

Network listeners

AJAX-based page changes are almost universally tied to XMLHttpRequests. These requests can be tracked from chrome code using a variety of methods, including web progress listeners, HTTP observers, and content policies. While these are not exceptionally efficient (they run for every HTTP request, and considerably more often for some methods), they work very well for certain applications

Pure CSS

Pure CSS can be more powerful than most people suspect. It is often possible to do things for which people have traditionally resorted to JavaScript with CSS alone. In particular, the ::before and ::after pseudo-elements, and pseudo-classes like :hover and :active can be used to achieve extremely complex dynamic behavior.

Late binding and event delegation

Often times, it suffices to bind event listeners to top-level elements and check for matching elements when the event fires. For instance, rather than watching for the creation of <a> elements and adding event listeners to them as they are created, an event listener can be added to the root <html> element, and when the event fires, the event.target and its parents can be searched for a matching element. You can read more about event delegation here.

It is important to note, however, that this method can have severe performance implications for certain events, namely mouseover, mouseout, and friends, which are fired very often while the mouse is moving.

Mutation observers

Mutation observers are the more efficient, W3C speced replacement for the highly inefficient mutation events. Their major advantage is in their performance and their ease of use, especially when combined with simple libraries. Their main disadvantage is that, due to their recent advent, support is currently limited to Firefox 14+ and Chrome 18. While they are still viable for add-ons targeting only the latest Firefox, those wishing to support older browsers will need to provide fallbacks.

CSS animation events

This technique, which works on Firefox 5+, has some particular advantages. Because it is based on CSS, it can be keyed to match new elements of any arbitrary CSS selector. And because it is CSS-based, and is triggered when CSS is being applied anyway, it does not slow DOM mutations. The technique was adapted from the method used by the X-Tag library.

The code below contains an inefficient fallback implementation for older browsers. It is worth noting, however, that while the animation-based implementation will fire any time an element which previously did not match the given selector is changed so that it does (when a class is added, for instance), the fallback will only match nodes when they are inserted into the DOM tree. Minor changes are also required if one wishes to support other browsers, or to run in non-chrome-privileged scopes.

XBL

XBL is similar in approach to the above animation-based method. Bindings are attached to DOM nodes via CSS and are given the opportunity to run code via their constructors when new matching DOM nodes are created. While it is no longer possible for web sites to use XBL directly, chrome code can still attach XBL bindings to web content from stylesheets loaded via the stylesheet service.

As it is currently possible to attach only a single binding to a given DOM node at once, it is important when using this method to detach your binding from a node once your constructor has run. This is most easily done by adding a :not clause to the CSS selector that attaches your binding. For instance, when using the selector div:not([foo-binding-done]), you can detach your binding by running this.setAttribute("foo-binding-done", true) in your constructor.

Monkey patching DOM methods

When you are interested in changes to particular nodes, sometimes the best way is to wrap the DOM methods of those elements, as in the monkey patching section above. For instance, if you need to know about attribute changes to a particular node, then you should replace its <code>setAttribute</code>() method with a function that calls the original setAttribute function as originalSetAttribute.apply(this, arguments) before running your necessary event code.