Top tip, devs – your Chrome extension doesn't have to suck: 'A few hours can result in big improvements for millions of users'

Coder urges peers to spend more time tuning plugins for performance

Matt Zeunert, founder of website monitoring biz DebugBear, has analyzed the performance of the 1,000 most popular Chrome extensions, and found that more than a few of them could be coded better.

The London-based developer detailed the Chrome extensions in an essay on Monday with an eye toward page CPU time, page rendering delays, background CPU time, and browser memory consumption.

Loading the website example.com in Chrome with no extensions took about 40ms in his test. Such measurements vary significantly depending on how, when, and where they're done, in terms of connectivity and system performance.

Using Chrome with Evernote Web Clipper and Grammarly, browser extensions with 4m+ and 10m+ users respectively, CPU time increased to over 500ms. That's not ideal since operations related to JavaScript processing and to page layout handling block the browser's main thread, delaying other processing.

Hitting you in the wallet

Such delays seem inconsequential in isolation, but once they add up to more than a second or two, website performance affects revenue. This may be a more pressing issue on mobile devices, where extensions aren't supported in Chrome, though there are other options, and delay sensitivity is greater. But it also matters for desktop-based and notebook-based browsing where extensions are common.

"Many users have several extensions installed, so a small performance impact can add up to a large negative effect on user experience," he wrote.

Evernote Web Clipper proved the worst of the top 100 extensions, adding a 2.9MB content script to every page loaded in the browser. The Chrome extension spends 140ms parsing and compiling the JavaScript code and then 300ms evaluating it after it's loaded.

Zeunert observes that this code isn't called on until the user clicks on the Evernote extension icon and the developers would do better to only load the code when needed. He points to a shopping extension called Honey that fixed its performance problems identified last year by checking whether it's needed before loading its script.

I think there's not enough attention on extension performance, given that many affect every single page load

"I think there's not enough attention on extension performance, given that many affect every single page load," said Zeunert in an email to The Register. "That means there's a lot of low-hanging fruit – a few hours of developer time can result in a big improvement for millions of users. It's very satisfying to see Honey go from 1s of run time a year ago to under 100ms now." Among the top 1000 Chrome extensions, the biggest page CPU delay came from Vigia de Preço, a Brazilan coupon and price watching extension with about 200,000 users. Zeunert found that it blocked the main thread for 1.6s, thanks to its use of a JavaScript browser fingerprinting library for token generation called fingerprintjs2.

Chrome extensions also often make use of a background page to run network processes and perform computations. The Avira Browser Safety fares poorly in the background CPU test, taking almost 3s running code in the background page, compared to other extensions that required less than 200ms.

One reason is the extension's allowlist has more than 30 regex (regular expression) pattern entries. Example.com is not on that list so the Avira Browser Safety extension searches alphabetically through the entire file. Looking up a site that's on the list like apple.com gets a hit much faster.

You've ad it

Ad blockers and privacy extensions turn out to be big consumers of browser memory, which they use to store domain blocklists. But they also reduce page and subframe memory consumption by not loading unwanted content. Using a news article requiring 536MB of memory as a test, a content blocker background page might require as much as 142MB with the least performant extension. At the same time, these extensions reduced page and subframe memory by as much as 640MB.

"The costs for most ad blockers aren't very large, but the benefits are huge when visiting an ad-supported site that's not optimized for performance," he said.

In terms of CPU time, DuckDuckGo Privacy Essentials led the back, taking the article page from 31s down to 1.6s by blocking 95 per cent of network requests and page weight by 80 per cent. Another extension, uBlock Origin, also performed well.

Google is in the midst of reworking its Chrome extension platform APIs under a set of rules referred to as Manifest v3. The company claims to be doing so to make Chrome extensions less of a drag on performance and more secure.

One change likely to have a significant impact is the deprecation and eventual removal of the webRequest API for everyone except enterprise users. The webRequest API is used to intercept and alter web requests in-flight, a capability that's both powerful and abusable. Its replacement, the declarativeNetRequest API, works with predefined rules, a less flexible approach than making decisions dynamically.

Zeunert acknowledges that the security concerns related to Chrome extensions are legitimate. "Currently Chrome extension permissions tend to be very broad," he said, noting that some of the extensions he evaluated got removed during his study. "For example, I noticed two extensions with identical code and very suspicious install counts. Out of my initial list of 1000 extensions – supposedly with hundreds of thousands of users – 17 were removed from the Chrome Web Store over the last few weeks."

But he finds Google's concern about performance problems arising from Manifest v2 extensions less compelling. He said his tests show that you can build performant ad blockers using the current extension API.

"Some ad blockers have poor performance, but not the most popular ones," he said. "Manifest v3 will make it easier to build performant ad blockers, but I don't think performance is a strong argument for deprecating the webRequest API."

He said there's also a risk that developers will try to work around the restrictions and introduce performance problems in the process. "For example, if developers can't get detailed statistics on what requests were blocked, they might instead use a content script to gather that information from within the page," he said. ®