Where Ads Get Cut
Intervention points in web advertisement blocking — the technique, and what the web's economy becomes when blocking works.
1 · The short version
An ad blocker is defined less by its rule list than by where on the page-loading timeline it cuts. Blocking early saves bandwidth, script execution, and layout stability. Blocking late only hides what the user has already paid for. This article defines the working vocabulary, maps the timeline, positions the common approaches on it, and closes with the economic endgame: what happens to the web when blocking actually works.
2 · Definitions — the fundamentals
- Advertisement / tracker
- A resource whose purpose is promotion or measurement, served by a third party — an origin different from the page you chose to visit. It is the third-party property that makes ads blockable without breaking the page's own function.
- First-party request
- A request to the page's own origin, or otherwise essential to its function. Blocking these breaks pages; a serious blocker must leave them alone by construction, not by user-configured apology.
- Filter rule
- A declarative statement: match conditions (URL pattern, initiator, resource type) → action (block, allow, collapse, rewrite). A blocklist is just a bundle of rules — the list is not the blocker.
- Intervention point
- The stage of the load timeline where a blocker's decision takes effect. The single most important technical property of any ad blocker.
- Network-level vs DOM-level
- Network-level decisions see URLs and origins but never the page's markup. DOM-level decisions see the markup — after everything has already been downloaded and partially executed.
- Layout slot & collapse
- Pages reserve space — a slot — for an advertisement before it arrives. Collapsing a slot removes the reserved space itself, so the page doesn't load with empty holes that later shift content around (measured as CLS, cumulative layout shift — a standard page-quality metric).
- Exemption
- An explicit allow-rule for flows that traverse third-party infrastructure but are user-critical: bot checks, OAuth sign-in, payment frames. Blocking well means knowing what not to block.
- Declarative vs imperative
- Declarative filtering: rules installed into the browser's network engine — fast, bounded, safe. Imperative filtering: code running against the page — flexible, expensive, risky. Modern browser platforms deliberately push filtering toward the declarative and gate imperative code behind explicit opt-in.
3 · The timeline: six places to cut
| Point | Stage — what is known there | Blocking here saves | What it still leaves behind |
|---|---|---|---|
| P1 | DNS / connection — hostname only | whole-network coverage, zero browser footprint | no URL path, no initiator, no markup — cannot exempt first-party flows or fix layout |
| P2 | Request issue — URL + initiator + resource type | bandwidth, scripts, all render cost — the theoretical minimum | the reserved slot is still empty |
| P3 | Response in flight | most of the payload | partial bandwidth already spent |
| P4 | DOM parse / scripts run | visibility | payloads loaded, code executed, blocking detectable |
| P5 | Layout / paint — space reserved | visual removal | layout shift if the slot is removed late |
| P6 | Post-paint — the live page | catches lazy and post-consent injections | everything already paid for |
Two rules follow. Everything later than P2 wastes something. And P6 never goes away, because modern pages inject advertisement slots lazily — after viewport triggers, after consent dialogs, on rotation timers. A complete blocker therefore cuts at P2, repairs at P5, and sweeps at P6.
4 · Where the common families sit
- DNS / VPN / proxy filters (Pi-hole, AdGuard Home, hosts schemes) live at P1 only: network-wide and invisible to the browser, but blind to paths, initiators, and markup — structurally unable to exempt first-party flows dynamically or to repair layout.
- Legacy request-cancellation blockers (the Manifest V2 era) held P2–P3 with full context. Chromium removed that ability; the model no longer ports to the dominant engine.
- Declarative MV3 filtering (declarativeNetRequest) holds P2 with full context, engine-fast and safe — but only cancels requests. The empty-slot problem is inherited, not solved.
- Cosmetic hiding (CSS injection) acts at P4–P5: it pays the full download and script cost first, and post-render hiding is the easiest posture for anti-adblock scripts to detect.
- Userscript surgery acts at P6 by default — the flexible escape hatch, not a foundation.
5 · The two capabilities almost nobody implements
- Pre-render slot collapse. When a request is blocked, the container reserved for it should collapse before first paint: the page loads clean — no holes, no shift, nothing for bait-detection scripts to measure. Network-level tools cannot see the slot; DOM-only tools act too late. Almost no mainstream blocker owns this layer.
- Post-boot sweep. A bounded audit of the live page re-applies the block to lazily injected slots. Not the primary filter — the closing of the loop that P6 demands.
And the quiet third: rule-expressible exemptions for bot checks, sign-in, and payment frames — the difference between a blocker that demos well and one that survives an actual shopping session.
6 · One implementation example
Script Lean — a small (~80 KB) MIT-licensed Chromium MV3 extension — implements exactly this composition: pre-request declarative filtering, pre-render slot collapse, rule-expressible first-party exemptions, opt-in userscript injection, and a bounded post-boot sweep; it reports passing the major public ad-block verification suites at 100%. Disclosure: this article's author maintains it. It is cited as evidence that the architecture fits the platform's constraints — not as a recommendation.
7 · Vision: when ads get cut, the economy goes peer
Today's web monetization is an arbitrage. Attention is harvested on the publisher's page and sold through surveillance intermediaries — the ad-tech layer prices the visitor's data, auctions it in milliseconds, and returns a fraction of the value to the creator. Effective blocking closes that arbitrage. Not gradually, not rhetorically: every request cut at P2 is a price signal that the harvest has stopped.
What survives that world is advertising that never needed surveillance in the first place — contextual ads, first-party promotions, sponsorship woven into the content itself. These are compatible with blocking by construction, because they do not depend on third-party tracking to be worth anything.
The rest of the funding must re-route — and the destination is peer-shaped: value flowing directly from the people who consume to the people who create.
- Patronage and memberships — recurring, direct, creator-owned.
- Micropayments and streaming value — open protocols like Web Monetization / Interledger, and Lightning payments over emerging social protocols, make pay-per-article and pay-per-minute viable where one-off card payments never were.
- Creators selling their own goods — the content becomes the storefront's front door instead of the ad network's inventory.
- Value-for-value communities — audiences funding what they actually consume, on rails where the payment is the native protocol action rather than an inserted third-party script.
The second-order effects are just as structural. Measurement migrates from third-party analytics to first-party community signals — the count that matters is the count of people who chose to pay attention. Discovery migrates from ad auctions to recommendation by peers and curators — a slower, less scalable, more honest mechanism. The ad-tech middle layer thins to what contextual placement genuinely needs. And "free content" stops meaning "paid for with your data".
The frictions are real and worth naming. Payment friction is the true bottleneck: paying must become as effortless as loading an ad was. Discovery without auction money is genuinely hard, and the long tail of the web lives on discovery. Access to payment rails is unequal across the world, so the transition lands unevenly — large platforms can wall themselves off long before independent creators can live on peer rails. None of this reverses the direction; it only sets the pace.
Seen this way, ad blocking and peer monetization are not opponents — they are two halves of one rebalancing. The blocker decides where the attention stops being for sale; the peer rails decide where the money goes instead. A web that cuts ads cleanly at the right points is not a poorer web. It is a web where the default flow of value no longer passes through the intermediary that made blocking necessary in the first place.