Residential and mobile proxies are billed by traffic, and three technical choices — what to load, what to compress and what to cache — shape the bill more than picking the cheapest channel. Here is what to block first, how response compression works, why cache between runs matters, and where savings start breaking the check itself.
Blocking images, fonts, video and trackers
Four resource types drive most of the savings. Images are the heaviest item on a product page — 2–5 MB per page. Fonts weigh less individually but load in batches — a few families easily add a megabyte per page. Autoplaying video is its own category: tens of megabytes per minute, and a feed that never stops eats traffic fastest. Trackers and ad scripts are lightweight themselves but drag in dozens of extra requests to third-party domains.
Blocking is configured at the automation tool level — intercepting requests by resource type (image, media, font) or by the domain of known analytics and ad networks. For text-only tasks — price, availability, status — blocking all four types does not change the result: the data lives in the HTML or API response, not the media files.
Response compression
An Accept-Encoding header with gzip, deflate, br tells the server the client accepts a compressed response; most servers compress text formats — HTML, JSON, CSS, JS — but leave formats like JPEG and MP4 alone, since recompressing gains nothing. The takeaway: compression mainly saves traffic on text pages and API responses, not pages with images, where the weight is media compression cannot shrink.
A proxy channel does not compress traffic on its own — that is configured server- and client-side. The proxy's role is passive: it forwards the response, compressed or not, so savings from compression do not replace savings from blocking media — they stack with it.
Cache between runs and skipping repeat page loads
Automation starting every run from a clean profile re-downloads static resources — fonts, library scripts, CSS — unchanged since the last run. A persistent cache directory reused between runs removes that waste: the browser pulls repeating files from local disk instead of the proxy again.
The second half of the savings is not requesting the same page twice within one task. Conditional requests with If-Modified-Since and If-None-Match let the server return a 304 with no body if the page has not changed — that saves nearly all the traffic on unchanged pages during repeat monitoring. Building proxy handling into automation is covered in proxies for browser automation.
Measuring savings before and after on a real task
Savings should be evaluated on a real task with a fixed set of pages, not a synthetic test. A "before" run: default settings, every resource loaded, traffic recorded from the account. An "after" run: the same pages, media blocking and cache on, the same counter. The gap is the actual savings for that task, not an average from someone else's case.
Check not just traffic volume but failed requests and retries: if a drop in volume comes with a rise in retries, part of the gain gets eaten back. Metrics for that check are in how to check proxy quality.
When the savings start breaking the check itself
Every technique above has a point past which traffic savings substitute for the task's actual result. Blocked images break the check if the task is visual: comparing a banner, screenshotting a storefront, testing responsive layout. Disabled scripts break parsing if content loads via JavaScript after the initial fetch — without running scripts, the page stays empty.
Stale cache is a separate risk: checking a current price or stock status against a cached response shows yesterday's data disguised as fresh. Savings on media and cache should switch off wherever the task checks the thing they hide: a dynamic price, a page's visual state, or content that depends on being current. Chasing the cheapest channel instead of tuning savings sensibly often backfires — covered in cheap versus expensive proxies.
Frequently Asked Questions
How much traffic does blocking images and video actually save?
On pages with media, 3–10x, depending on the original image count; on video feeds, an order of magnitude more, since autoplay without blocking burns tens of megabytes a minute. Only a before/after run on your own task gives an exact figure — averaged estimates from other projects miss your pages' structure.
Can already-loaded images be recompressed on the fly through a proxy?
Regular proxies do not re-encode or recompress media — they forward the server's response as is. Traffic-transformation services exist, but that is a separate product, not a property of a residential or mobile channel; cheaper to simply not load media the result does not need.
How do I tell whether cache or media blocking broke the check instead of saving traffic?
Compare the task's result, not just traffic volume: if the price, availability or status no longer matches a manual check on the site, savings touched something that should have stayed unchanged. Run that comparison regularly, not just once at setup.
A channel picked for the task — residential and mobile addresses billed by traffic, or datacenter ones billed monthly — is in the proxy section.