Blocking Ads Where Requests Are Born: Why Opera Put Its Blocker in the Browser Core

Every time a page loads, your browser fires off dozens of requests you never asked for: ad scripts, tracking pixels, sponsored widgets. Most browsers outsource the job of refusing those requests to an extension. Opera made a different engineering call years ago: it built the ad blocker into the browser itself, right next to the network stack. That decision, which looked like a convenience feature at the time, has aged into something more interesting — a preview of where the whole platform was heading.

Two places to say no

There are two fundamentally different points where a browser can refuse a request.

An extension-based blocker historically worked through Chrome's webRequest API: the browser issues the request, hands it to the extension, waits for a verdict, and then either continues or cancels. That round-trip costs time, and in the worst case the resource is partially fetched or the ad renders briefly before being hidden — the familiar "ad flash" followed by a layout jump as the page reflows.

Opera's blocker is native. Because Opera has been a Chromium/Blink browser since 2013, its engineers could hook filtering directly into the request pipeline. A request is matched against filter lists — EasyList-style syntax, the same grammar the major blocking lists use — and a matching request is cancelled before anything is downloaded. The script never executes, the image never renders, and the page layout never has to recover from an element that appeared and vanished. The address-bar shield icon shows a per-page count of blocked items, and clicking it lets you exempt the current site.

The practical difference is not ideological; it's mechanical. Cancelling a request before the fetch avoids wasted bytes, avoids the flash-and-shift, and removes the extension IPC hop from the critical path of every request on every page.

The Manifest V3 vindication

The decision looks even better in hindsight. Chromium's Manifest V3 platform moved extension blocking away from live webRequest interception toward a declarative model: extensions declare static rule sets, the browser enforces them, and rule counts are capped. That change constrained exactly the architecture classic filter-based blockers relied on.

Opera's in-core blocker was never subject to any of that. It doesn't consume an extension rule quota, it doesn't depend on an API Google can deprecate, and it doesn't need a third-party maintainer to keep pace with platform changes. The thesis writes itself: if a capability is load-bearing for the browsing experience, it belongs in the browser, not bolted on through an API surface you don't control.

A worked example you can reproduce

You don't have to take anyone's benchmark numbers for this — including vendor-published ones, which age badly. Measure it yourself in about ten minutes:

1. Create a clean Opera profile so no extensions or cached state interfere. In Settings, search for "block ads" and confirm the feature is off.
2. Open DevTools (F12), go to the Network panel, check "Disable cache," and load a known ad-heavy news homepage. Note three numbers: total requests, transferred bytes, and the DOMContentLoaded time in the bottom status bar.
3. Enable the blocker in Settings, hard-reload the same page, and record the same three numbers.
4. Cross-check: the shield badge's blocked-item count should be in the same ballpark as the drop in request count. In the Network panel, blocked requests typically appear as failed/cancelled entries — filter by the ad domains you saw in the first run to confirm they're the ones that disappeared.

On a typical ad-heavy page you should see a meaningful reduction in both request count and transferred bytes, because blocked resources are never fetched at all. Run each configuration two or three times and take the median; first-load variance from DNS and TLS setup will swamp the signal otherwise. These are your numbers on your connection — which is exactly why they're more trustworthy than a chart in a press release.

What you give up

Honesty requires the other column of the ledger:

• Less control. Opera chooses the default filter lists. You can add custom rules and per-site exceptions, but the cosmetic filtering (hiding annoying page elements that aren't network requests) and the community tooling around something like uBlock Origin are far richer.
• Anti-adblock walls. Some publishers detect blocking and refuse to serve content. A built-in blocker is just as detectable as an extension — arguably more so, because sites can fingerprint the browser itself.
• Scope confusion. Opera's ad blocker is not its tracking protection, and neither is its "VPN" (a browser-scoped encrypted proxy). They have different mechanisms and different guarantees; don't assume one implies the others.
• Publisher economics. Default-on blocking in a shipped browser intensifies the funding problem for ad-supported sites. Per-site exceptions are the pressure-release valve, and they're worth using for sites you value.

Also note that desktop Opera, Opera GX, and the mobile variants don't necessarily share defaults or UI placement — verify anything above against the specific build you're running, because settings labels and filter defaults shift between releases.

The takeaway

Opera's native blocker is a small feature with a clear architectural lesson: request filtering is most effective — and most future-proof — when it happens inside the browser's network pipeline rather than through an extension API. Run the DevTools comparison above on your own machine, add one site exception and one custom filter rule to see both escape hatches work, and then decide whether the built-in defaults are enough for you or whether you still want a dedicated extension on top. Either way, you'll be choosing based on measurements, not marketing.