What does blocking trackers actually buy you?
Here's the data.
An independent benchmark tested 119 top U.S. news sites under three conditions — no blocking, DNS-level blocking, and browser-extension blocking — and measured exactly what changed.
119 real sites, three conditions, one automated harness.
The benchmark used a Puppeteer-driven testing harness running in Docker to load each site in a fresh browser instance and record load time, DOMContentLoaded time, total bytes transferred, request counts, third-party request counts, and unique hostnames contacted. Every site was tested three times, once per condition:
- Baseline — no blocking of any kind, default browser.
- DNS-level blocking — AdGuard DNS, the same filtering layer Bloqr automates.
- Extension blocking — AdGuard's browser extension, filtering inside the page.
The site list was drawn from NewzDash's top U.S. news publisher rankings, combined with FeedSpot's top news sites. The results below reflect the 119-site run captured in March 2025.
Averages across all 119 sites.
DNS-level blocking — with nothing installed on the device — recovers most of the gain a browser extension gets, simply by refusing to resolve tracker and ad domains before a connection is ever attempted.
| Metric | Baseline | DNS blocking | Δ vs. baseline | Extension blocking | Δ vs. baseline |
|---|---|---|---|---|---|
| Page load time | 11,271 ms | 7,356 ms | -35% | 6,190 ms | -45% |
| DOMContentLoaded | 3,909 ms | 3,216 ms | -18% | 3,148 ms | -19% |
| Page weight | 6.07 MB | 4.32 MB | -29% | 3.72 MB | -39% |
| Total requests | 299.2 | 177.8 | -41% | 144.9 | -52% |
| Third-party requests | 220.3 | 101.9 | -54% | 68.6 | -69% |
| Unique hostnames hit | 74.4 | 20.5 | -73% | 11.3 | -85% |
The same handful of companies, over and over.
In the unblocked baseline run, these companies showed up most often across the 119-site sample — the adtech and analytics stack that DNS-level filtering removes before a single request goes out:
- Google115/119 sites
- The Rubicon Project (Magnite)82/119 sites
- comScore81/119 sites
- Amazon79/119 sites
- Microsoft78/119 sites
- PubMatic77/119 sites
- Criteo76/119 sites
- Index Exchange74/119 sites
Same category of gain, different place in the stack.
The benchmark above treats DNS blocking and extension blocking as interchangeable — they land within a few points of each other on every metric. But they get there by operating at completely different layers, and that difference is what actually determines coverage, maintenance, and who you have to trust.
Client-side, application layer (browser extension)
An extension like uBlock Origin sits inside the browser, so it can inspect the full HTTP response, the DOM, and CSS — letting it hide specific page elements, not just block requests outright. That precision comes at a cost: it has to be installed and kept updated on every browser, on every device, separately. It also lives at the mercy of the browser vendor — Chrome's move from Manifest V2 to Manifest V3 deliberately constrained the declarative rule APIs ad blockers depend on, and Google has an obvious conflict of interest as a company whose primary revenue is advertising. An extension covers nothing outside the browser: no IoT devices, no OS-level telemetry calls, no third-party desktop apps phoning home.
Client-side, OS layer (local proxy application)
Installing a filtering application on the device itself — rather than just the browser — extends coverage to every process on that machine, including desktop apps like Adobe's Creative Suite or Windows' own telemetry and ad surfaces. It typically works by running an invisible local proxy that intercepts traffic before it leaves the device, which means you're trusting that proxy with visibility into everything the machine does. It still only covers one device at a time — rules and lists have to be installed and kept in sync across every computer and phone you own — and it still doesn't reach IoT devices or anything without an OS a client can be installed on.
Server-side, DNS layer (DNS sinkholing)
DNS-level blocking doesn't proxy traffic at all — it works more like a firewall for name resolution, dropping the lookup for a known-bad domain before a connection is ever attempted. Point a router or a device's DNS settings at a filtering resolver (or run a local resolver such as Unbound) and every device on that network is covered from a single point of configuration — no per-device install, no per-browser sync. It's the only architecture of the three that can also carry encrypted-DNS transport (DoT, DoH, DoQ) and Oblivious DoH, and dropping a blocked query costs the resolver essentially nothing computationally: a no-op, not extra processing. The trade-off is precision — DNS blocking can't reach into a page's DOM or target individual CSS selectors, so it can't hide a specific on-page element the way an extension can, only stop the request for it entirely.
What doesn't change, no matter where you block
- IP exposure. Every architecture above still leaves your IP address visible to whatever you connect to, unless it's paired with Oblivious HTTP / Oblivious DoH.
- Unencrypted DNS by default. DNS queries travel in plaintext unless the resolver and client both support an encrypted transport — Bloqr encrypts DNS queries by default regardless of which layer is doing the blocking.
- The sync problem. Client-side approaches (extension or OS-level) require rule lists to be installed and kept current on every device separately, unless you're running your own central DNS server or forwarder to distribute rules from one source of truth.
This isn't Bloqr's research. We're citing it because it's good.
This benchmark was designed and run independently by Maxim Topciu as the open-source project research-ad-blocking-web-performance, released under the MIT license. Bloqr had no role in designing the methodology or collecting the data — we're presenting the results here because they're a clean, reproducible illustration of what DNS-level filtering (the mechanism Bloqr automates) actually does to page performance.
Why DNS-level blocking needs encryption to matter.
The performance numbers above assume your DNS queries even reach the resolver doing the blocking — and by default, those queries travel unencrypted and readable by anyone on the path. Our whitepaper on encrypted DNS breaks down what DoT, DoH, DoQ, and Oblivious DoH actually change, and why encrypting the transport still isn't the same as trusting the resolver.
Get the DNS-level win, automatically.
Bloqr keeps the filter lists behind DNS-level blocking current across every DNS provider you use — no extension, no client software, no manual syncing.