最近国外一个网站debugbear发布了其对谷歌浏览器Chrome的插件测试结果，测试了1000种最受用户欢迎​​的Chrome扩展插件的性能表现,主要指标有CPU消耗，内存消耗，扩展以及对页面渲染速度的影响。我们今天就一起来了解下该测试结果，并希望以此来指导我们对插件的选择。

Top100扩展的性能影响

所有性能测试结果详见debugbear网站（debugbear /chrome-extension-performance-lookup）

首先我们来看最常用的100个跨站和他们的表现。这所有的Top100的扩展都有超200万的下载量。测试主要从四个不同方面的指标：

页面CPU时间：页面主线程忙了多长时间，它在做什么；

页面渲染延迟：页面显示某些内容之前需要多长时间；

后台CPU时间：扩展在后台执行多少处理；

浏览器内存消耗： 浏览器的不同组件使用多少内存。

页面CPU使用率

JavaScript执行或运行布局逻辑会阻止浏览器主线程。这时候浏览器将无法和用户进行交互。如果没有安装任何扩展程序，加载example.com大约需要40毫秒的CPU时间。如果安装了Evernote或Grammarly，则需要500毫秒以上。

下图表中显示了Top100 Chrome扩展中最慢的20个扩展。其他80个扩展总共增加了不到100ms的CPU时间。

研究发现这些扩展并不是在特定站点下才表现很慢，而是对用户打开的每个页面都添加代码。我们看看他们的行为，比如Evernote Web Clipper扩展。

Evernote扩展拥有超过400万用户。它向每个页面添加了2.9MB的内容脚本。仅140ms用于解析和编译该代码。

脚本加载后，还需要对其进行解析，这又耗费了300毫秒。

实际上该代码没有任何用处，除非用户单击了Evernote扩展程序图标。代码设置了一个事件侦听器，该事件侦听器在用户单击图标时触发，但是无需加载完整的JavaScript包即可完成。

其他类似的行为也出现在Grammarly, Clever, Avira Password Manager和Skype扩展中：

扩展通常会将代码注入每个页面，而不是仅针对特定域。Password managers需要检查是否有登录表单。Spell检查器需要查找文本字段。

但是，为了提高性能，将检查相关条件的代码与扩展的主要功能分离开会更好。然后，大多数代码仅在必要时加载。

一个有趣结果是，尽管Skype加载很大JavaScript包，但也只会增加150ms的CPU时间。据猜测是，这是由于代码主要由静态配置对象和易于解析和评估的长字符串组成。

Ghostery

很惊讶地看到Ghostery在列表中相对靠前。与其他扩展程序不同，它实际上在页面上执行某些操作，显示阻止了多少跟踪器。

Ghostery加载了160KB的JavaScript，并增加了120ms的CPU时间，数量不算太多。但是，其中一些代码对页面渲染是阻塞的。

页面渲染延迟

尽管额外的CPU时间意味着该页面在一段时间内没有交互，但这通常不会完全阻塞页面的呈现。

大多数扩展都没有或仅引起了很小的渲染延迟。下图显示了对初始内容呈现具有最大负面影响的扩展。

Chrome扩展程序可以定义应注入到页面中的脚本和样式表。默认情况下，一旦页面加载完成并处于空闲状态，它们就会添加到页面中。

但是，扩展开发人员可以在页面开始加载后立即加载这些资源。例如，Dark Reader扩展程序将网站内容更改为黑暗主题。首先以明亮的主题呈现页面，然后突然过渡，这会很烦人。这种在页面开始呈现之前运行代码是有意义的。这种代码的数量应减少到最小。

好消息是，引起页面100ms以上的延迟的扩展只有6个：

Clever, Grammarly, Rakuten Get Cash Back for Shopping, LastPass

在页面开始呈现之前，这些扩展都运行大量代码。Clever页面内容的显示时间比未安装扩展程序的显示时间延迟了300毫秒。

AVG/Avast SafePrice

尽管SafePrice不会等到页面空闲后再注入脚本，但它会等到文档加载完毕。不确定这是为什么，但是以某种方式，JavaScript代码似乎仍然可以在初始渲染之前就运行。

后台CPU使用率

并非浏览器扩展所做的所有处理都在用户可见的页面上进行。大多数Chrome扩展程序都有一个称为"背景页面"的页面，通过该页面，扩展程序可以执行诸如侦听网络请求或更新扩展程序图标之类的操作。

Avira Browser Safety在后台页面上花费近3秒钟来运行代码，而所有其他扩展花费不到200毫秒。

后台页面通常运行代码以响应用户打开的页面发出的网络请求。上一个测试的页面仅发出一个网络请求，远远少于正常情况。再次运行了该测试，这次加载了Apple主页，该页面发出了大约50个请求。

有趣的结果是，这次Avira表现的明显快了很多，从2.7秒提高了600毫秒！这是怎么回事？

原来Avira Browser Safety安全扩展包含一个网站许可清单，其中包含30k+正则表达式。当用户导航到新页面时，Avira将检查页面URL是否在该允许列表中：

{

key: "_isWhitelisted",

value: function _isWhitelisted(url) {

return !!this._whitelist && this._whitelist.some(function (pattern) {

return pattern.test(url);

});

}

}

而Apple.com处于允许列表中，并且由于该列表按字母顺序排序，因此该功能很快就完成。Example.com不在列表中，因此要通过针对所有3万个正则表达式模式检查URL。

浏览器内存消耗

Chrome扩展程序可能会增加用户打开的页面和扩展程序后台页面中的内存消耗。

同样，Avira Browser Safety是列表的第一，增加内存消耗218MB。这同样是由于30k+正则表达式，要将它们被编译为字节码或机器码，并需要存储在内存中。

一些背景页面也包含iframe，例如Amazon Assistant扩展：

具有背景页面的扩展名至少增加10MB的内存消耗。如果没有后台页面，只有一个小的页面脚本，那么扩展对内存的影响就可以最小化。

top1000名扩展程序的性能影响

让我们来看一些100k+用户不太受欢迎的扩展。

页面CPU使用率

前面Evernote具有最大的负面性能，将CPU时间增加了560ms。top1000扩展中有9个扩展名，其消耗更大。

榜首的是Vigia dePreço，他巴西一个的优惠券应用，有20万用户的价格监控扩展。它会阻塞主线程1.6秒。其中很大一部分是使用Fingerprintjs2生成令牌。例如，涉及渲染图像并为其生成数据URL，以便检测浏览器是否支持某些Canvas功能。

榜眼扩展Snap&Read有超过100万用户，用来可帮助他们阅读和理解文本。它会在每个页面上加载一个3.8MB的lexicon.js文件，这耗费了大部分解析和编译时间。如果将用JSON保存可能会更加高效。

然后，它处理的词汇和负载一堆类库，比如jQuery，pdfmake和citeproc。总计Snap&Read会对每个页面加载7.5MB的JavaScript代码。

第三位的壹伴.小插件是一个拥有30万用户的中文Chrome扩展程序。主要是在扩展微信网络编辑器，它会在每个页面上加载4MB的代码。

然后是MozBar，这是一个拥有70万用户的SEO工具。除非实际单击扩展程序图标，否则它似乎并不会执行太多操作，但仍然要运行3MB的代码。

页面渲染延迟

扩展是否阻止页面呈现？大多数时候，没有。

壹伴.小插件会加载14个内容脚本，这些脚本需要700毫秒以上的时间才能开始呈现页面。

在呈现页面之前，Axe加载了两个大小1.8MB的脚本。

后台CPU使用率

查看背景页面，没有其他扩展超出Avira Browser Safety和Avira Safe Shopping占用的。

Bitdefender TrafficLight是一个具有60万用户的安全扩展程序。它根据可能有安全问题的数千个条件列表检查请求URL。为此，它会遍历该列表并检查当前URL是否匹配。

浏览器内存消耗

有趣的是，在没有广告的页面上，广告拦截器会大大增加浏览器的内存消耗。这主要是由于其存储大量的阻止URL列表。

广告拦截器对性能的影响

测试中测试了20种广告拦截器和隐私工具在加载WCPO新闻时的性能影响。

页面CPU使用率

DuckDuckGo Privacy Essentials将文章页面的CPU时间从31s减少到仅为1.6s。所有其他经过测试的扩展也使CPU时间消耗最多减少10s。

大多数广告拦截器通过阻止由页面启动的某些网络请求来工作。DDG Privacy Essentials将网络请求数量减少了95%，下载率减少了80%。

后台CPU使用率

Chrome扩展程序需要进行一些处理，决定哪些请求需要阻止。这项工作发生在后台页面。因此，尽管广告拦截器可以极大节省页面上的CPU时间，但它们也会在后台略微增加。

为什么这些插件有很明显的差异？广告拦截器会存储要屏蔽哪些请求的条件列表，然后需要将请求URL与该列表进行匹配。

Ads Blocker RP会迭代一千多个正则表达式，并检查它们是否与请求网址匹配。这样做可能需要10毫秒，如果发出数百个请求，占用很快就会累加起来。

而DDG Privacy Essentials基于请求域进行简单的对象属性查找，该操作实际上是瞬时的。

浏览器内存消耗

广告通常在与首页内容隔离的iframe中投放。经过测试的新闻文章的子subframe使用536MB的内存。

运行广告拦截器后台页面会占用一些内存，如果使用广告拦截器，则最多可占用142MB。

但是，运行的效果是最大减少了640 MB的页面和subframe内存消耗，远远超过他们消耗的。

Top100名开发工具的性能影响

让我们看看Chrome Web Store的开发工具类别中排名前100位的扩展程序。

页面CPU使用率

只有少数几个工具会显著地增加页面上的CPU时间。

SEOquake在页面顶部显示一个栏，导致页面重新布局并重新渲染。即使没有对页面记录测试，Selenium IDE也会注入700KB的JavaScript。

页面渲染延迟

除了axe，没有其他开发人员工具明显造成渲染延迟。

在页面开始呈现之前，axe会加载三个内容脚本。其实上这是可以避免的，因为仅当用户单击Chrome DevTools中的按钮时才运行可访问性测试。

后台CPU使用率和浏览器内存消耗

这项目中没有什么有趣的东西。后台CPU使用率始终低于120ms。ChromeVox导致内存消耗增加最多，但增加了80MB。

扩展开发优化方法

扩展开发人员其实可以通过一些方面加速扩展的性能。下面是一个可供参考的建议：

通过仅在必要时加载脚本来限制性能成本。

尽可能使用Chrome扩展程序平台提供的URL过滤器。

请使用一个小的脚本来检测扩展程序是否需要在页面上执行任何操作。然后用该小脚本来再引入和加载其他代码。

强烈避免在document_start上加载内容脚本。如有必要，保持其大小在100KB以下。

避免递归访问数千个URL过滤条件的列表，尤其是当这些条件依赖于复杂的逻辑或正则表达式时。

如果在运行时以编程方式更新扩展程序图标，请对该操作进行反跳操作。每次更新只需要大约25毫秒，但是如果在加载页面时会更新图标10次。

结论

大多数网站至少需要一秒钟的时间来加载，因此，如果扩展添加了额外的100ms，用户甚至可能都不会注意到。但是，在每个页面上执行操作会累加。许多用户已安装了多个扩展，因此对性能的较小影响可能会对用户体验造成较大的负面影响。