Google Pushes Back Chrome modifications that Would Break Ad Blockers
Google is relaxing the changes of Chrome ad blocker extensions that would have impacted ad blockers, since the performance penalty during web browsing could be significant.
Google announced last October Manifest V3, a new standard for developing Chrome extensions. The Manifest V3 document contained many new rules about what Chrome functions and APIs an extension should use. One of the modifications was for extensions that needed to intercept and work with network requests. Google wanted extension developers to use the new DeclarativeNetRequest API instead of the older webRequest API.
But the new API came with limitations that put a muzzle on the number of network requests an extension could access. Ad blocker developers and regular users soon accused Google of trying to kill third-party ad blockers for the detriment of Chrome's new built-in ad blocker.
A study analyzing the performance of Chrome ad blocker extensions published on Friday showed that the new Chrome browser would have eventually killed off ad blockers and many other extensions.
The study, carried out by the team behind the Ghostery ad blocker, found that ad blockers had sub-millisecond impact on Chrome's network requests that could hardly be called a performance hit. It found that the Manifest V3 proposal of the Chromium project performs "arbitrary JavaScript".
The study --which analyzed the network performance of ad blockers such as uBlock Origin, Adblock Plus, Brave, DuckDuckGo and Cliqz'z Ghostery-- found sub-millisecond median decision times per request, showing quite the opposite of what the Chrome team claimed.
"The extensions ecosystem on Chrome is vibrant and varied, and enables myriad use cases that would otherwise be impossible. We are committed to preserving that ecosystem and ensuring that users can continue to customize the Chrome browser to meet their needs. This includes continuing to support extensions, including content blockers, developer tools, accessibility features, and many others. It is not, nor has it ever been, our goal to prevent or break content blocking," said Chrome engineer Devlin Cronin.
"Moving towards the open web allows the extension system to move forward as the web moves forward, and moving away from a long-running persistent process with a full DOM can have very real impact on resource usage. We understand that, for some scenarios, these gains are less critical - with a powerful machine, the extra resource cost is not always noticeable. However, we feel that Chrome should provide a great browsing experience to all users, including those on less powerful machines (such as old hardware and the growing market of entry-level laptops), where these resource drains are incredibly impactful. Good performance on low-end devices is critical," Cronin added.
"Another clarification is that the webRequest API is not going to be fully removed as part of Manifest V3," Cronin said.
" We won’t launch Manifest V3 until it is ready, and there will be a migration period in which we can continue to address feedback and issues. We will not remove support for Manifest V2 until we are confident in the platform," Google's engineer added.