小编典典

MutationObserver在整个DOM中检测节点的性能

javascript

我对MutationObserver用于检测某个HTML元素是否添加到HTML页面中的任何位置感兴趣。例如,我要说的是,我想检测是否<li>在DOM中的任何位置添加了。

MutationObserver到目前为止,我所看到的所有示例仅检测是否将节点添加到特定容器中。例如:

一些HTML

<body>

  ...

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

  ...

</body>

MutationObserver 定义

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
});

因此,在此示例中,MutationObserver设置用于监视非常特定的容器(ul#my-list),以查看是否将任何<li>附加到其上。

如果我不想 那么具体 ,是否<li>在整个HTML正文中关注,是否会出现这样的问题:

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

我知道它可以在我为自己设置的基本示例中起作用…但是不建议这样做吗?这会导致性能下降吗?如果是这样,我将如何检测和衡量该性能问题?

我认为也许有一个原因,所有MutationObserver示例都针对其目标容器如此具体…但是我不确定。


阅读 818

收藏
2020-05-01

共1个答案

小编典典

此答案适用于大型页面和复杂页面。

特别是如果在页面开始加载之前附加了观察者(即document_start/ document-start在Chrome扩展程序/
WebExtensions /userscripts中,或者仅在内部的常规同步页面脚本中<head>),但在庞大的动态更新页面上(例如,在GitHub上进行比较)。如果页面是大而复杂的未优化MutationObserver回调可以添加几秒钟的网页加载时间1,2。大多数示例和现有库都没有考虑到这种情况,而是提供了美观,易用但缓慢的js代码。

MutationObserver回调是作为微任务执行的,该微任务阻止DOM的进一步处理,并且每秒可以在复杂页面上触发数百或数千次。

  1. 始终使用devtools分析器,并尝试使您的观察者回调所消耗的时间少于页面加载期间消耗的总CPU时间的1%。

  2. 通过访问offsetTop和类似属性避免触发强制同步布局

  3. 避免使用复杂的DOM框架/库(如jQuery),更喜欢使用本机DOM。

  4. 观察属性时,请使用中的attributeFilter: ['attr1', 'attr2']选项.observe()

  5. 只要有可能,请非递归地观察直系父母(subtree: false)。
    例如,通过document递归地观察等待父元素,在成功时断开观察者的连接,在此容器元素上附加一个新的非递归对象是有意义的。

  6. 当仅等待具有id属性的一个元素时,请使用快速的速度,getElementById 而不是 枚举mutations数组(它可能有成千上万个条目):example。

  7. 例如,如果所需元素在页面上相对较少(例如iframeobject),则使用getElementsByTagName和返回的实时HTMLCollection getElementsByClassName并重新检查所有元素,而不是枚举mutations如果它具有100个以上的元素。

  8. 避免使用querySelector,尤其是极慢的速度querySelectorAll

  9. 如果querySelectorAll在MutationObserver回调中绝对不可避免,请首先执行querySelector检查,如果成功,则继续进行querySelectorAll。平均而言,这样的组合会快很多。

  10. 如果定位到非出血边缘浏览器,请不要使用需要回调的内置Array方法(如forEach,filter等),因为在Chrome的V8中,与经典for (var i=0 ....)循环相比,这些函数的调用总是昂贵的(慢10到100倍) ,但V8团队正在研究[2017]),并且MutationObserver回调可能每秒触发100次,addedNodes在复杂的现代页面上每批次的突变都有数十,数百或数千个。

数组内置的内联不是通用的,通常发生在类似基准的原始代码中。在现实世界中,MutationObserver的活动具有间歇性的峰值(例如每秒1-1000个节点每秒报告100次),并且回调从未如此简单,return x * x因此无法检测到代码“热”得足以内联/优化。

但是由lodash或类似的快速库支持的替代功能枚举是可以的。从2018年开始,Chrome和底层V8将内联标准数组内置方法。

  1. 如果定位不流血的边缘浏览器,不要使用慢速ES2015圈像for (let v of something)MutationObserver回调里面,除非你transpile从而使得到的代码的运行速度是经典的for循环。

  2. 如果目标是改变页面的外观,并且您有一种可靠,快速的方法来告知所添加的元素不在页面的可见部分之外,请断开观察者的连接,并通过以下方式安排整个页面的重新检查和重新处理setTimeout(fn,0):解析/布局活动的初始爆发完成,引擎可以“呼吸”,甚至可能需要一秒钟。然后,您可以使用例如requestAnimationFrame显着地处理页面。

回到问题:

观察一个非常确定的容器ul#my-list,看是否<li>有附加的容器。

由于li是直接子节点,并且我们正在寻找添加的节点, 因此唯一需要的选项childList: true(请参阅上面的建议2)。

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

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