> 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:
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.