Performance Chrome扩展对页面加载时间的影响

我正在编写一个Chrome扩展，我想测量它如何影响性能，特别是目前我对它如何影响页面加载时间感兴趣

我选择了一个我想测试的页面，用Fiddler录制了它，我用这个录音作为Fiddler中的自动应答器。这使我能够在没有网络流量延迟的情况下测量负载时间

使用这种技术，我发现我的扩展增加了约1200毫秒的加载时间。现在，我试图找出延迟的原因，但在理解DevTools的性能结果时遇到了困难

首先，报告的加载时间似乎存在差异： 一方面，摘要显示了~13秒的范围，但另一方面，加载事件在~10秒后到达（我还使用

performance.timing.loadEventEnd-performance.timing.navigationStart

证实了这一点）：

第二件我不太明白的事情是这个数字是怎么加起来的（或者说不加起来）。例如，以下是加载期间不同类别的分组：

这两列的总和既不等于10秒，也不等于13秒

当我按域分组时，我可以为扩展和其他内容获得不同的行：

但是，延长时间似乎只增加了250ms，这远远低于负载时间的差异

我假设这些数字只代表CPU时间，不包括任何等待时间。这是正确的吗？如果是这样的话，那么这些数字不加起来也没关系，而且扩展可能没有把所有的时间都花在CPU限制的工作上

此外还有神秘的[Chrome扩展开销]，这也不能解释加载时间的差异。从它与我的扩展是一条独立的线路这一事实来看，我认为它们是相互排斥的，但如果我深入研究细节，我会在[Chrome extensions overhead]子域下发现我的扩展的功能：

总而言之，这就是我希望能够做到的：

• 计算我的扩展使用的总CPU时间-看起来它不足以在扩展名下查找，它的函数也可能出现在其他组中
• 了解加载时间延迟是由CPU处理还是同步等待引起的。如果是后者，请查找我的扩展在哪里执行同步等待，因为我非常确定我没有调用任何阻塞API

更新

最终我发现，导致速度放缓的原因是，每当我们的扩展运行时，我们都会激活Chrome可访问性，这就是导致速度急剧放缓的原因。没有可访问性，扩展的影响很小。我仍然想知道，我怎么能在分析器中看到我的问题是可访问性。这本可以帮我节省很多时间。。。稍后我将再次尝试查看它。

“自底向上”面板仅显示CPU时间。Self time表示函数内的代码，total=Self+此函数调用的所有其他函数。根据扩展的实际功能，有多种方法可以减缓页面加载过程。例如，它可能会向请求队列中添加缓慢的外部内容。试着比较两个火焰图表是否有你的分机。