Hacker News Reader

Comment by saagarjha | Hacker News Reader

> This work was motivated by one of the claims formulated in the Manifest V3 proposal of the Chromium project: "the extension then performs arbitrary (and potentially very slow) JavaScript", talking about content-blockers' ability to process all network requests. From the measurements, we do not think this claim holds, as all popular content-blockers are already very efficient and should not incur any noticeable slow-down for users. Moreover, the efficiency of content-blockers is continuously improving, either thanks to more innovative approaches or using technologies like WebAssembly to reach native performance.

I don't think it's valid to debunk this claim without testing the speed of manifest/content blocker list-based blocking.

View on HN

I believe this article does debunk the Google performance claim. It doesn't really matter if the "manifest" system is perfectly fast (exactly 0 seconds); this article shows that the current blockers are fast enough that they are indistinguishable from zero. There is limited room for improvement here (so limited as to be effectively none).

Again, it doesn't debunk it because the claim isn't "Current content blockers are not performant", it is that the API allows extensions to do things which cause performance issues, and there's a long tail of extensions that use this API and do create human noticeable delays. If you cherry pick performant examples and then try to debunk the whole landscape, it simply doesn't work.

> Again, it doesn't debunk it because the claim isn't "Current content blockers are not performant", it is that the API allows extensions to do things which cause performance issues, and there's a long tail of extensions that use this API and do create human noticeable delays.

Both of these arguments are easily rebutted and have already been in this thread. As others have pointed out, the modified API still allows extensions to do things which cause performance issues, just not in that particular path. (Also, preventing ad load can improve page load performance so much that even a "slow" adblocker may make up the difference anyway.)

> If you cherry pick performant examples

I don't think these examples are cherry-picked; they're among the most popular adblockers in the landscape:

* https://www.tomsguide.com/us/pictures-story/565-best-adblock...

* https://www.digitaltrends.com/web/best-ad-blockers-for-chrom...

As others have pointed out, you can measure and break or shame poorly performing blockers without punishing the ones that work well. So:

> and there's a long tail of extensions that use this API and do create human noticeable delays.

There's a long tail of extensions that are poorly behaved in general. You can punish those ones without killing the ones that don't suck.

Hey, disclaimer: I worked on this study.

I would love to hear your thoughts about this. From our point of view, the argument is not that the native content blocker is slow or fast but instead that it's not an acceptable trade-off, for different reasons (see link below). We also show that some of the most popular content-blockers are more than fast enough in this regard. I would love Chrome to propose this declarative API as an addition to the current WebRequest APIs and incentivize developers to use it when it makes sense. But replacing the current WebRequest's blocking capability with this would prevent extensions from protecting users as efficiently as today.

I wrote a bit more about other reasons I think the declarative API as only blocking capability of the browser is not a good thing IMO: https://news.ycombinator.com/item?id=19175265

Reply on news.ycombinator.com