Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Adblockers Performance Study

whotracks.me

Post reply on HN
Print view View original

51–60 of 126 posts

Re: Adblockers Performance Study

#51

Post by mirashii »

loeg wrote: post #41
saagarjha wrote: post #16

> 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…

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.

Re: Adblockers Performance Study

#52

Post by btown »

QuercusMax wrote: post #4
ra7 wrote: post #2

Can we not have editorialized title please?

Yeah... that's barely even what the article is about, based on a brief skim. They seem to disagree with what Manifest v3 is trying to accomplish, but the article doesn't even use the word "bullshit". (Disclaimer: I work for a non-Google Alphabet company.)

Agree with the need not to editorialize, but that is indeed what the article is about. The entire impetus for measuring the performance impact of ad blockers is to disprove one of the two cited reasons for Manifest v3, namely that there are real-world measurable performance benefits to preventing ad blockers from intercepting web requests.

Re: Adblockers Performance Study

#53

Post by danShumway »

magicalhippo wrote: post #6

FWIW, Chromium devs have just responded[1] to the massive amount of feedback they got on the mailing list, like [2] and [3]. One of the main pain points raised was the lack of any way to dynamically add rules, as well as the low maximum number of rules allowed (30k). Seems they've decided to support dynamic rule addition, as well as increasing the number of rules, though probably not by orders of magnitude by the sou…

Dynamic rule addition addresses a very small number of complaints with the proposal.

Beyond the ability to block requests conditionally based on arbitrary logic (not just a few pre-decided qualifications like request size), one point I want to keep coming back to is that there are actually legitimate reasons why an extension might choose to slow down requests. I use Tampermonkey scripts on a couple of social networking sites deliberately to slow them down so I'll that I'll be less likely to impulsively refresh them.

I continue to believe that the manifest changes aren't written with the perspective of enabling creative, unseen uses of the API in the future. They're written from the perspective of, "let's decide up-front what extensions we want, and enable specifically them."

The feedback people have given on this is extremely broad, and is mostly ignored by this post. It's disappointing to see a response that at least somewhat suggests the Chrome team is dead set on shipping this, and is only willing to bend so far as it takes for them to enable the most popular adblockers that exist today. If it took that much feedback to get Chrome to even slightly tweak the design, then what possible feedback can people give going forward to make anything more significant happen?

Re: Adblockers Performance Study

#54

Post by pythux »

seanwilson wrote: post #48

> 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…

> It might be the case these adblockers are well written but you can't guarantee that for all extensions. If a user doesn't have an obvious way to know it's the fault of an extension then Chrome gets the blame.

It has been suggested in another comment that Chrome could give visual indications of the performance of extensions. They already do some of this to track the memory used.

Re: Adblockers Performance Study

#55

Post by move-on-by »

Thanks for the interesting read! Just right off the bat, I’m a little cautious of benchmarks done by Ghostery that happens to show Ghostery is incredibly fast. Not that anything else stood out to me as suspicious, just a comment. Perhaps they are The fastest _because_ they are benchmarking and have fixed bottlenecks.

Beyond all that, I’m a huge fan of ad blockers and use them as an attempt to reduce tracking and targeting and it’s abundantly clear to me that they greatly speed up many webpages. The amount of junk that so many sites load, no doubt it even saves me data on my data plan.

It seems like common sense to not trust a company whose main income is based on advertising to be making decisions on ad blocking.

Re: Adblockers Performance Study

#56

Post by pythux »

move-on-by wrote: post #55

Thanks for the interesting read! Just right off the bat, I’m a little cautious of benchmarks done by Ghostery that happens to show Ghostery is incredibly fast. Not that anything else stood out to me as suspicious, just a comment. Perhaps they are The fastest _because_ they are benchmarking and have fixed bottlenecks. Beyond all that, I’m a huge fan of ad blockers and use them as an attempt to reduce tracking and targ…

Thanks a lot for your comment. The project is open source and everything needed to run the study comparisons is available as well there: https://github.com/cliqz-oss/adblocker/tree/master/bench/com...

We would be really happy to see people running the same benchmarks and try to reproduce the results!

Re: Adblockers Performance Study

#57

Post by loeg »

mirashii wrote: post #51
loeg wrote: post #41

Earlier quoted context omitted.

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.

Re: Adblockers Performance Study

#59

Post by stordoff »

StreamBright wrote: post #28
kkm wrote: post #10

Earlier quoted context omitted.

- As pointed out in the previous comment, with DNS based blocking users often have to choose between convenience and privacy. As an example: Blocking ads on Youtube with DNS blocking is very hard, unless you block youtube* itself. - It does not give you fine grained permission: Like, if you only want to allow a particular third-party on a specific site. While DNS based blocking is fast but at the same time it is also…

Youtube is an interesting example, I use it less and less because of ads but can you block ads in it with anything? The problem for me is that I have several devices that do not run JS (like TV box) and do not use a browser for watching content. For this reason it is probably the only solution to block bad content on the DNS level. I like to pay for what I get (Netflix) and I reject the entire ad based surveillance c…

With a combination of Pi-Hole and uBlock Origin, I never see ads on YouTube.

Re: Adblockers Performance Study

#60

Post by stordoff »

thetinguy wrote: post #5
StreamBright wrote: post #3

Also, how about blocking on the DNS level? Why does this article concerned with in browser ad blocking only? I bet it is much less resource utilisation if you do it in lower layers.

DNS adblocking sucks because it takes too long to turn off when a website breaks because of ads.

I don't find that. Logging into my Pi-Hole and disabling it temporarily takes about 10 seconds, and with how infrequently it happens it's a non-issue.
Post reply on HN