The finders define functions that run periodically (usually every five seconds) to detect important elements the watchers might have missed.
Watchers are generally hierarchical, and reference other tags to explore smaller and smaller DOM subtrees. The watchers declare parts of the page structure that we know will change - things like the thread and message list containers, and the compose and reply buttons. The declarations consist of realtime watchers and polling finders, which pick out specific elements and add them to tracked sets of elements dubbed “tags.” page-parser-tree observes subsets of a dynamic webpage, using declarations provided by the developer that identify important sections of the page.
Throttling mixmax code#
Instead of registering global MutationObserver instances, or leaning heavily on fragile, specialized code to watch the right elements for changes, we now make heavy use of page-parser-tree, a module written by Chris Cowan at Streak. If we made our declarations too specific, we would risk significant maintenance work to respond to Gmail changes, but if we make them too indirect, we risk missing crucial page updates that allow us to introduce our own controls into Gmail. We realized early on that a good solution must balance performance and reliability. Optimally, we would (instead of watching all changes) identify nodes we expect to change and observe them directly. We wanted to maintain functionality without the massive performance penalty. In our case, we discovered that simply running this check was enough to induce low performance, as our mutation observers fired their handlers with such intensity that it overwhelmed poor V8. Underscore’s throttle function returns a closure function which checks the elapsed time since the last call, and delegates to the provided function only when sufficient time has passed. To combat the expected performance issues endemic to responding to every little change in the DOM, we wrapped our handler in _.throttle, thereby only responding to a small fraction of changes without losing correctness.
We were using this approach to observe page changes within Gmail without undue risk of breakage from changes in Gmail’s page structure. Our performance analysis revealed that our existing implementation configured MutationObserver instances to watch for changes anywhere within the document tree, causing major page slowdown. This code was thus a candidate for optimization. Our performance analysis showed significant processing time being spent in the code that observed the page for changes. Sadly, many users previously reported performance problems with Gmail when Mixmax was installed. As we did this, we attached our own content to the page. For years, we achieved this by crafting query selectors to identify important elements within Gmail’s DOM, and continuously re-applying these selectors as the page changed. In order to add features to Gmail for our users, we need to track the structure of Gmail’s DOM and be able to manipulate it. Our product, and its convenience and power, depends on tight user-interface integration with Gmail. The previous post on December 6th was about Database-backed job processing. This blog post is part of the Mixmax 2017 Advent Calendar.
0 kommentar(er)
