2020 Chrome Extension Performance Report

June 14, 2020 · 14 min read

Update: read the 2021 Chrome Extension Performance Report

I tested how the 1000 most popular Chrome extensions affect browser performance.

The main metrics I'll consider are CPU consumption, memory consumption, and whether the extension makes pages render more slowly.

Here's a list of all tested extensions and their results (this link now shows 2021 data).

Update 8 July 2020: I originally reported the simulated FCP metric provided by Lighthouse rather than the First Contentful Paint observed in the browser. I've now updated the charts and the list of extensions.

Outline

Top 100
Top 1000
Ad blockers
Developer Tools

Tips for extension developers
Conclusion

Performance impact of the Top 100 extensions

Let’s start by looking at the 100 most used Chrome extensions. Each of these has been installed more than 2 million times.

We’ll look at four different metrics:

Page CPU time How long is the page main thread busy for, and what is it doing?
Page rendering delays How long does it take until the page displays some content?
Background CPU time How much processing does the extension do in the background?
Browser memory consumption How much memory do different components of the browser use?

Page CPU Usage

JavaScript execution or running layout logic blocks the browser main thread. This means the browser can’t respond to user interactions.

If no extension is installed loading example.com takes around 40ms of CPU time. If you’ve installed Evernote or Grammarly this jumps to over 500ms.

This chart shows the 20 slowest extensions out of the 100 most used Chrome extensions. The other 80 all add less than 100ms of additional CPU time to the page.

On-page CPU time by Chrome extension, Top 100

Rather than targeting specific sites, these extensions add code to every page opened by the user. Let’s take a look at what some of they are doing.

Evernote Web Clipper

The Evernote extension has over 4 million users. It adds a 2.9MB content script to every page. 140ms are spent just parsing and compiling that code.

Evernote trace showing code being parsed, compiled, and executed

Once the bundle has been loaded it needs to be evaluated, which takes another 300ms.

Does this code actually do anything? As far as I can tell, no, not unless the user clicks the Evernote extension icon.

The code does set up an event listener that’s fired when the user clicks the icon, but this can be done without loading the full JavaScript bundle.

Grammarly, Clever, Avira Password Manager, Skype

This pattern of loading large amounts of unnecessary code repeats with other Chrome extensions.

Extension	Page Script Size	Page CPU Time
No Extension	0MB	42ms
Evernote Web Clipper	2.9MB	559ms
Grammarly	1.3MB	507ms
Clever	2.6MB	335ms
Avira Password Manager	1.5MB	405ms
LastPass	0.8MB	241ms
Skype	1.5MB	191ms

Extensions often need to inject code into every page, rather than only targeting certain domains. Password managers need to check if there's a login form. Spell checkers need to look for text fields.

However, for performance it would be much better if the code that checks the relevant conditions was separated from the primary functionality of the extension. Then most of the code would only be loaded when necessary. Honey made this change last year and it greatly reduced their performance impact.

Interestingly, Skype only adds 150ms of CPU time, even though it has a large JavaScript bundle. My guess is that this is due to the code mostly consisting of static configuration objects and long strings that are easy to parse and evaluate.

Ghostery

I was surprised to see Ghostery relatively high up in the list. Unlike the other extensions it actually does something on the page, namely displaying how many trackers were blocked.

Ghostery loads 160KB of JavaScript and adds 120ms of CPU time – not a huge amount. However some of this code is render-blocking, as we’ll see in the next section.

Page rendering delays

While extra CPU time means the page isn’t interactive for some time, this doesn’t normally completely block the page from rendering. To see if an extension blocks rendering we can look at the First Contentful Paint metric – when the browser starts to display text or images.

Most extensions introduce no or only minor rendering delays. This chart shows the extensions with the largest negative impact on initial content rendering.

Note that the FCP impact of Avira isn't caused by request blocking logic running in the background. We'll see what's going there in the next section.

Impact of Chrome extension on First Contentful Paint

Chrome extensions can define scripts and stylesheets that should be injected into the page. By default these are added to the page once the page has finished loading and is idle.

However, extensions developers can decide to load these resources as soon as the page starts loading. For example, the Dark Reader extension changes website content to a dark theme. It would be jarring to first render pages in a bright theme and then suddenly transition. Here it makes sense to run the code before the page starts to render.

The amount of this code should be reduced to a minimum. The good news is that only 12 of the extensions in the chart cause a rendering delay of more than 100ms.

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

These extensions all run significant amounts of code before the page starts rendering. In the case of Clever, page content only starts showing 300ms later than without the extension installed.

AVG/Avast SafePrice

While SafePrice doesn’t wait until the page is idle before injecting scripts, it does wait until the document has loaded. I'm not sure why, but somehow the JavaScript code still appears to run before the initial render.

SafePrice Trace showing FCP after content scripts have run

Background CPU Usage

Not all processing that a browser extension does happens on a page that's visible to the user. Most Chrome extensions also have something called a background page which lets the extension do things like listen to network requests or update the extension icon.

Background page CPU usage, with Avira spending alsmost 3s while Ghostery is a far-off second with 180ms

Avira Browser Safety spends almost 3s running code in the background page, while all other extensions spend less than 200ms.

Background pages often run code in response to network requests made by the page that was opened by the user. The page from the previous test only makes one network requests, far less than normal. So I ran this test again, this time loading the Apple homepage, which makes around 50 requests.

Background page CPU usage when loading Apple homepage, Ghostery spend a bit over 1s

Interestingly Avira is now significantly faster, 600ms instead of 2.7s! What’s going on?

The Avira Browser Safety extension contains a website allowlist with 30k+ regular expressions. When the user navigates to a new page Avira checks if the page URL is in that allowlist:

{
  key: "_isWhitelisted",
  value: function _isWhitelisted(url) {
    return !!this._whitelist && this._whitelist.some(function (pattern) {
      return pattern.test(url);
    });
  }
}

Apple.com is in the allowlist, and because the list is sorted alphabetically the function quickly finishes. Example.com is not in the list, so the extension ends up checking the URL against all 30 thousand regex patterns.

Browser memory consumption

Chrome extensions can increase memory consumption, both in pages opened by the user and in the extension background page.

Again, Avira Browser Safety is at the top of the list, increasing memory consumption by 218MB. This is due to the 30k+ regular expressions – I think they are compiled to bytecode or machine code, which needs to be stored in memory.

Browser memory consumption – 140MB with no extensions, many extensions raise that by 100-200MB

Some background pages also contain iframes, for example the Amazon Assistant extension:

DevTools Elements tab for Amazon Assistent background page showing multiple iframes

An extension with a background page increases memory consumption by at least 10MB. If there’s no background page and only a small on-page script then an extension's the memory impact can be minimal.