Free tool
Ad Blocking Speed Impact
Measure how much of a page is advertising and tracking rather than content, in real requests and real bytes.
Why bytes understate the real cost
The byte figure above is the easiest cost to measure and the least important one. What actually makes an ad-heavy page feel slow is connection overhead and main-thread work, neither of which shows up in a download total.
Consider a single analytics script of 40 KB on a domain the browser has never contacted. Before it can arrive there is a DNS lookup, a TCP handshake and a TLS negotiation, each a full network round trip. On mobile that can be 300 milliseconds before the first byte. Then the script executes on the main thread, during which the page cannot respond to taps. A 400 KB image on an already-connected host is often cheaper than that 40 KB script.
What blocking changes
| Cost | Effect of blocking |
|---|---|
| Bytes downloaded | Removed entirely for every blocked request |
| Connection setup | Removed, often the largest single saving on mobile |
| Main-thread execution | Removed, which improves responsiveness more than load time |
| Layout shift | Reduced, since late-arriving ad slots no longer push content around |
| Battery and data | Reduced proportionally on metered and mobile connections |
How this measurement is made
The scanner fetches the page, enumerates its subresources, and issues a real request for each one to read its declared size. Anything matching a known advertising or tracking signature is counted as tracker weight; everything else is counted as content.
Two honest caveats. Only the first sixty resources are measured, so a very heavy page reports a floor rather than a total. And because this reads the initial HTML, resources loaded later by JavaScript are not included, which again biases the result downward. The number you see is conservative in both directions.
The methodology we are not using
A common approach is to load the page twice in a headless browser, once with a blocker and once without, and report the difference in load time. It produces a satisfying number and it is extremely noisy: ad auctions return different creatives on every load, CDN routing varies, and the same page measured twice can differ by seconds for reasons unrelated to blocking.
Measuring bytes and requests gives a smaller number but a stable and reproducible one. We would rather publish a figure that holds up than a larger one that moves every time you refresh.
To see which specific companies account for the weight on a given page, run the same address through the tracker scanner.
Frequently asked questions
Do ad blockers actually speed up browsing?
On ad-heavy pages, substantially. Enter an address above to see the measurement for a specific page: how many requests and bytes go to advertising and tracking rather than to the content you asked for. On a lean site the saving is negligible; on a commercial news site it is often a quarter or more of the page.
How much data do ads use?
It varies enormously by site. The tool sizes every subresource with a real request rather than estimating, so the byte figures shown are measured. Resources that do not report a size are counted in the request total and excluded from the byte total, and the result says how many those were.
Is the time saved figure measured?
No, and the tool says so. Bytes are measured; the time figure is derived from those bytes at a stated connection speed. Real page load time depends on latency, connection count, script execution and render blocking, which a server-side scan cannot reproduce. Treat it as a scale indicator rather than a benchmark.
Why do trackers slow pages down more than their size suggests?
Because bytes are only part of the cost. Each third-party host needs its own DNS lookup, TCP connection and TLS handshake before a single byte arrives, and analytics scripts frequently execute on the main thread, delaying interactivity. A small script on a new domain can cost more than a large image on one already connected.