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

Question

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

我选择了一个我要测试的页面，用Fiddler录制它，我将这个录音用作Fiddler中的AutoResponder。这使我可以测量加载时间，而不会造成网络流量延迟。

使用这种技术我发现我的扩展加载了大约1200毫秒的加载时间。现在我想弄清楚导致延迟的原因，我无法理解DevTools性能结果。

首先，报告的加载时间似乎存在差异： 一方面，摘要显示的范围为~13s，但另一方面，load事件在~10s之后到达（我也使用performance.timing.loadEventEnd - performance.timing.navigationStart证实了这一点）：

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

这两列中的任何一个都不是10s，也不是13s。

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

但似乎扩展只增加了250ms，远远低于负载时间的差异。

我假设这些数字仅代表CPU时间，并且不包括任何等待时间。它是否正确？如果是这样，那么数字就不会加起来，并且扩展可能不会花费所有时间来进行CPU绑定工作。

然后还有神秘的[Chrome扩展开销]，它也没有解释加载时间的差异。从它与我的扩展分开的一个事实判断，我认为它们是相互排斥的，但如果我深入了解细节，我会在[Chrome扩展开销]子域下找到我的扩展功能：

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

• 计算我的扩展程序使用的总CPU时间 - 看起来不足以查看扩展名的名称，其功能也可能出现在其他组中。
• 了解加载时间延迟是由CPU处理还是同步等待引起的。如果是后者，找到我的扩展程序正在进行同步等待的位置，因为我很确定我没有调用任何阻塞API。

更新

最终我发现减速的原因是我们在扩展程序运行时也激活了Chrome辅助功能，这就是导致急剧放缓的原因。如果没有可访问性，扩展的影响非常小。我仍然想知道，我怎么能在剖析器中看到我的问题是可访问性。它本可以节省我很多时间......我会稍后再试一次。