I'm going to be downvoted for saying this but... ublock origin actually does slow down rendering your webpage. I think that it's sad that there seems to be so much pushback from vendors in regards to options like ublock origin, but I have found equally impressive results with system wide options like adguard without it reducing the speed of pages rendering.
Yes, I’m going to downvote you, but only because you misunderstand how ad blocking works. uBlock does marginally slow down webpage render because it has to inject CSS rules (cosmetic filters) to improve blocking quality. If you don’t want this feature, you can disable cosmetic filtering entirely within uBlock’s settings.
The problem with AdGuard is that they charge for system-wide blocking which can be done for free with a hosts file or pi-hole.
Let me please chime in. As AdGuard developer, I'd like to comment on what you said and explain some details about how it works.
First of all, AdGuard desktop and mobile apps are quite different from hosts files or pi-hole. For instance, they're also able to apply cosmetic rules. Also, and this is really important on Android (unfortunately we can't do that on iOS), AdGuard is able to apply different rules depending on which app makes a request.
The common example is dealing Facebook Audience network. If you need to block Facebook ads in third-party apps with Pi-Hole, you'll have Facebook official apps broken as well. With AG, you can keep the official FB app working and block it in third-party apps at the same time.
Second, on every platform save for iOS, AdGuard filters every network connection and not just DNS queries. There're already multiple examples of apps (for instance, TikTok) that switch to using DOH when they detect that there's DNS filtering messing with their domains. Eventually, every network-level blocker, pi-hole included, will have to control all connections as DNS simply won't be enough.
> For instance, they're also able to apply cosmetic rules.
How does this happen? Do you inject the thousands of CSS rules from EasyList in each page? Doesn't this require AdGuard to be able to have access to the response body for secure connections? Doesn't this mean that web pages can easily override injected cosmetic filters since these are not injected as user styles?
1. Yes, it basically injects a CSS stylesheet into every page + a JS script that does additional filtering.
2. Yes, in order for this to work, AG will need to access response body.
3. Yes, and in this case we'll need to use JS-based filtering (so-called extended CSS rules or scriptlets).
And here's an answer to the question you didn't ask: yes, this would be slower than doing the same with a browser extension. To make it faster, a different approach to filter rules is required - fewer generic cosmetic rules, more HTML filtering and removing elements from the page content.
The end goal is to completely get rid of any app or extension. Ideally, I'd like to see all the filtering moved to a server-side application like AdGuard Home.
If all pages were static this would’ve worked beautifully.
But they aren’t, and uBO approach also implies that there is a mutation observer constantly monitoring DOM changes and adding new rules when they are needed. In a browser extension it uses browser’s own RPC to pass DOM nodes to the background page, check them, and apply new rules when needed.
In our case we would’ve needed to use something like a websocket to do it, but WS may be quite problematic. And the overall performance gain from this DOM-survey approach is milliseconds, it’s not something that a person can notice.
No, AdGuard desktop is basically a full-scale firewall with a network driver that intercepts all network connections.
Regarding Android, this works with the help of the VPN API.
1. Android routes all IP packets to the “tun” interface
2. AdGuard reads them, passes through its own small tcp/ip stack. On one side there is the tun device, on the other side there are real sockets to the IP packets destinations.
3. App detection can be done either by reading /proc/net/tcp or, on newer Android versions, by using special getConnectionUid method.
Regarding secure connections, besides IP filtering (which AG also can do) there is always SNI scanning. Also, there’s an option to MITM connections, in this case AG generates a unique CA locally and does all the certs validation by itself.
I read more about how AdGuard works on the website (which is what I should have done in the first place, instead of making assumptions on how it works). I’m quite impressed, especially with Android, at how much control AdGuard has over network traffic. I’m left with a few questions.
- Many apps ignore the device certificates and instead use their own certs which come installed within the app itself (to prevent MITM attacks). How does AdGuard deal with this?
- iOS is much more restrictive. Other than Safari’s content-blocking API, does AdGuard for iOS only do DNS filtering?
- I’m not surprised that apps like TikTok are using DOH to circumvent filtering, but I can’t find a source online confirming this. Could you point me to an article/repo issue/etc. which confirms this practice and lists other apps that also do this?
1. SSL pinning is not actually that widespread. However, it is used by quite popular apps - Facebook and Twitter. Unfortunately, there is no way to deal with it without patching the apps itself. Also, modern Android versions limit the trust for user certs, basically only browsers trust that type of certs. The solution would be to move the cert to the system store, but it requires root.
2. It’s not iOS that’s restrictive but Apple. We can’t even mention anywhere in the app that you can block something using DNS filtering. We’re playing this reject-phonecall-reject-appeal game for two years already and I simply have no confidence that if we bring all the functionality to iOS they allow this. Other than that it’s possible and rather easy to do, the core filtering engine is implemented in C++ and we use it on all other platforms.
3. This is from talks with filters maintainers. But yeah, this is a good topic for an article, we should write one. Thanks for the tip:)
edit: my desire for moving filtering to the server-side actually comes from the experience of communicating with different stores. Also, Chrome’s upcoming changes contribute to my paranoia. Slowly, step by step, users are losing control over their own devices and apps.
It’s almost as if the browser should provide an method for extensions to identify things to block, in a way that is optimised for performance and privacy, rather than just throwing even more JavaScript into the page.
However, this API could be used to optimize some of (not all of) the networking filtering that uBO does. Network filtering is distinct from cosmetic filtering, the latter is what injects scripts into every page.
The uBO wiki has some nice documentation of the different features, measurements of their overhead, etc. E.g.: https://github.com/gorhill/uBlock/wiki/Doesn't-uBlock-Origin...
Great so not javascript running "in the context" of the page.. just javascript running.. somewhere else, for every single network request that is made, and that still has access to the page.
I know a lot of web developers don't want to hear this, but throwing more javascript at the problem isn't always the best solution.
You are being presumptuous about my knowledge in regards to ad blocking. So I'll explain in further detail why I personally use adblock, and why ublock is unnecessary.
Second, adguard is free. There are certain premium features, however. For instance, filtering ads outside of your browser requires a premium license. However, if you are comparing it to ublock this was already not a feature that was available to you.
Of course, even that comes with an addendum, which is that this is only something that you need to worry about on mobile devices. Should you be using the desktop version you will actually see that adguard is free and available here on github: https://github.com/AdguardTeam/AdGuardHome
In regards to pi-hole. The cumbersome nature of pi-hole makes it undesirable for me. There were many sites which were blocked for inexplicable reasons the last time I used a pi-hole and creating a whitelist for these sites requires more work than is necessary. First you must navigate to the portal, and then you must make changes to either the whitelist, or remove a site from the blacklist depending upon why the site is not accessible. It was not seamless design. However, those that find this feature desirable will find that adguard actually offers the same experience with adguard home: https://github.com/AdguardTeam/AdGuardHome
And as a matter of fact you will notice that there are comparisons between ublock origin available on the github page for your review. There are actually a number of features which are missing from ublock which are simply not possible with ublock origin. As for the accuracy of these features you’ll have to determine that on your own but you can review them here: https://i.imgur.com/5fSLuHx.png
Also, ublock origin does not marginally slow down a webpage rendering. It significantly slows down a webpage rendering. As evidenced here:
That means that when you are running ublock origin your browser is working at 87.85% capacity. Or in otherwords, a 13.15% decrease in speed. To put this in real world terms it would be similar to reducing the speed to 50mph* on a road that was originally 60mph.
So feel free to keep using ublock origin. As a matter of fact I also use it occasionally in a pinch. (It does, after all, significantly speed up rendering of some webpages. I find it especially useful on webmd.) However, for my daily driver I find it to be a poor solution.
> That means that when you are running ublock origin your browser is working at 87.85% capacity.
No it's not, at this point your are spreading FUD about uBO.
This is a benchmark specialized for one thing, the creation/deletion of DOM nodes, a completely unrealistic scenario in the real world -- web sites do not repeatedly create nodes just to have them deleted as soon as they are inserted, as fast as possible.
uBO's code which deals with the DOM represents a fraction of what uBO needs to do, and yet you extrapolate the benchmark as if it represents all the work uBO does, leading to your nonsensical conclusion.
Here is how uBO compares to other comparable content blockers with an actual real-world scenario, as per recent debugbear benchmark[1] -- it's the least CPU hungry of the bunch: https://twitter.com/gorhill/status/1273263792785326085
Note that the above is a worst-case scenario for content blockers, since this was about loading a page from `example.com`, where nothing is blocked, consequently where a content blocker acts only as an overhead. See reference [1] for a more typical scenario.
I don't know what to conclude about ad blocker perf from Speedometer, but it's not just creation/deletion of DOM nodes. It runs multiple implementations of TodoMV using various JS frameworks[1, and performs real operations in the web app. DOM is not the bottleneck. The test stresses many parts of the engine, JS, CSS, HTML, rendering, etc.
Google's V8 team (not the original creators of Speedometer, that was WebKit) did a study of real-world JavaScript and found that it was highly correlated with Speedometer[2]. It's likely to be a good proxy of load time and responsiveness for many web sites, especially ones built with modern JS frameworks.
I don't know why uBlock Origin would slow down Speedometer and I'm actually surprised to hear it's true.
Care to comment about the debugbear benchmarks? Why is the supposed undue overhead as per SpeeDOMeter not showing up in there?
I encourage whoever to actually speculate less and measure page load times from the top 500 Alexa and make the case that uBO is an issue CPU- and memory-wise. I confidently predict that you will find that there is no correlation to the SpeeDOMeter benchmark.
There are other 3rd-party benchmarks out there which also found that uBO does indeed save CPU and memory resources.[1][2][3]
Then my explanation would be that these measurements measure different things than Speedometer. CPU time is a power metric, First Contentful Paint is a page load speed metric, memory is a memory metric, none of these are web app responsiveness measurements. All of these data points can be true at the same time!
Personally, I would expect any content blocker that does a lot of blocking to speed up page load, reduce memory use, and save power, because less stuff loads and less stuff gets processed. That any ad blocker would reduce Speedometer score is kind of a surprise to me, but if it's real, I believe it.
I really have no stake in which ad blocker is best or more efficient. I just wanted to clarify what Speedometer does, and why it's a relevant measurement.
I admire your work, gorhill, I do. However I'm not convinced of your results. Lets go ahead and run some benchmarks. First, would you mind tell me how you can about your results?
How did you come about your results? Did you use selenium? Or did you catalog all the data by hand? Also, do you have the data available? I'm going to run the tests myself, and any insight would be appreciated. I would especially appreciate it if you could allow me to review the data you have on hand but I understand if you don't want to provide it.
Also, slightly beside the point but is Raymond.cc your site? Just curious.
Yeah, no. Javascript manipulates the dom exactly as you are describing. In fact, javascript is directly responsible for much of the rendering on the modern web today. Hacker News goes in circles talking about it lately, in fact.
So any page with javascript is going to be slowed down precisely for the reason you are stating.
All you have done is compared a bunch of chrome extensions. Adguard is not an extension. Being faster than all the extensions is like being smartest boy who got held back a grade.
I responded to your claim _"It significantly slows down a webpage rendering"_, and provided 3rd-party evaluation to the contrary when actual real world web pages are used.
You counter with a just-trust-me claim that AdGuard not-the-extension is fastest, no objective evaluation provided -- despite AdGuard the-extension not faring the best among the bunch in actual real-world, independent evaluations.
Well, to be honest, AdGuard not-the-extension technically cannot be the fastest. It does a lot of things to do system-wide blocking - analyzing the connection, passing network packets, parsing protocols, this all adds some overhead. Browser extensions simply don't deal with all that stuff and thus any extension, unless it's really poorly written, is not slower.
Moreover, this is not what we are offering. System-wide blocking is about having more control over your system and not about being the fastest.
The point I was trying to make is that cosmetic filtering slows down the browser, period. AdGuard is not more efficient at applying CSS rules than uBlock.
uBlock Origin speeds up most pages because it actually prevents things from loading that would slow down the page. Whereas a during benchmark it's really just sitting there idling.
I'm sorry but that's definitely not true. It does not prevent things from loading. They still load, but they are scrubbed from the page. A DNS filter like adguard and pihole actually does what you are describing.
> They still load, but they are scrubbed from the page
Misinformation, again.
uBO prevents DNS requests from being made in the first place for requests which are meant to be blocked. This way the browser will know faster that a network request is meant to be blocked, it does not have to wait for a DNS resolver to respond.
Additionally, as a result of being in-browser, uBO is also able to collapse the placeholder counterpart of any of network requests which were cancelled.
I am skeptical system-wide blockers would slow down less, especially considering the browser has to fire the network requests no matter what, while in-browser blockers prevent blocked network requests from being fired at all.
