Bandwidth & cost · MOOPROXY FIELD NOTES
Align the units first
In decimal units, 1 GB is 1,000,000,000 bytes. In binary units, 1 GiB is 1,073,741,824 bytes. The same byte count produces different displayed numbers: 1 GiB is approximately 1.074 GB. Applications do not always label their conversion clearly.
Compare raw byte counts and explicit conversion rules where possible. This article explains measurement; the actual plan's units, upload/download scope and multipliers are defined by the product's rules and account records. A client metric is not itself a billing guarantee.
A saved file is only one part of the transfer
A page can load stylesheets, scripts, images, fonts and API data after its HTML arrives. Polling, preloaded media and WebSocket messages may add more. None of these necessarily appear in the saved HTML file. A failed download can also have transferred part of its body before failing.
| Metric | What it measures | What it can miss |
|---|---|---|
| Saved file size | Final stored content | Other resources, uploads, failed attempts |
curl size_download |
Transferred response-body bytes, excluding headers | Uploads, headers and other connections |
| Browser resource size | Decoded or transferred size, depending on the column | Different cache accounting or requests outside the page |
| Proxy-side record | Traffic under the service's metering rules | It need not equal any single client metric |
curl documents separate fields for size_download, size_header and size_upload. With --compressed, decoded output size can differ again.[1] HTTP Content-Encoding identifies encodings such as gzip or Brotli; it does not imply that every resource compresses by the same percentage.[2]
Work through a simple budget
Suppose a task downloads 2.0 MB of required documents and dependencies. Running it 1,000 times transfers approximately 2,000 MB. If 100 retries transfer an additional 1.5 MB each, they add 150 MB, for 2,150 MB before uploads, headers or other traffic included by the service's rules.
These are illustrative numbers, not a MooProxy benchmark or a fixed cost per page. Retries that fail before receiving a body transfer less; failures near completion can transfer much more.
Estimated transfer = successful-attempt data
+ data already transferred by failed attempts
+ required background requests and uploads
Cost per useful result = actual batch cost / valid result count
Isolate unexpected usage
- Use an isolated account or time window. Pause other jobs on that account and record the balance and timestamp.
- Run a small, fixed batch with the same region, task count and page-ready condition.
- Inspect request count, resource types, redirects and retries in application logs or the browser Network panel.
- Allow metering updates to arrive, then compare balances with consistent units and multipliers.
- Change one variable at a time before repeating the batch.
Two balance readings cannot isolate a test while unrelated jobs continue using the same account. Reporting delays also matter, so retain the complete time window.
Optimize requests without breaking results
For text-only tasks, consider skipping images or media and validate the extracted fields afterward. Screenshot or visual-checking jobs usually need those assets. Separate authentication failures from transient connectivity problems so that a fixed error does not trigger endless retries.
Connection pooling can reduce setup overhead, and caching can avoid repeated resources. However, Playwright request routing disables HTTP caching. The right trade-off depends on whether the task revisits pages and which resources it needs.
Measure both traffic and output correctness. A cheaper run that misses fields or requires reprocessing may cost more per useful result.
Sources and editorial notes
Sources checked on 2026-10-19. Original synthesis based on official documentation. Code illustrates configuration; it is not a production performance claim.
Ready to validate your connection?
Generate a configuration and start with a small test.