How Much Residential Bandwidth Do You Need?

Residential plans are sold by volume, so buying is really a forecasting exercise. Get it wrong in one direction and you run dry mid-project; get it wrong in the other and you pay for capacity you never consume.

Here is a method that produces a defensible number in under an hour.

Start from real measurements

Do not estimate from how big a page feels. Measure.

Fetch a representative sample of the exact pages your job will touch, through the proxy, and record the transferred bytes. Sample several page types, because they differ a lot:

• A listing or category page.
• A detail page.
• Any API or JSON endpoint you will use.
• A search results page, if applicable.

Log bytes, not just status codes. Most HTTP clients expose response size, and a session-level byte counter is even better.

Count your requests honestly

Work out requests per run from the shape of the job, not from a target you hope for:

• How many items does one run cover?
• How many pages per item, including pagination?
• How many runs per day or week?
• Does each run re-fetch data that has not changed?

Then multiply. The common mistake is forgetting retries and forgetting sub-resources.

Add the retry multiplier

If your realistic success rate is 90 percent, you need roughly 11 percent more attempts to get a full result set. If it is 70 percent on a defended target, you need about 43 percent more.

Use your measured success rate rather than a guess. The method is in Latency vs Success Rate. This multiplier is also why a cheaper provider can cost more, since a lower success rate means more attempts.

The calculation

Putting it together:

monthly_gb = items_per_run
           * pages_per_item
           * runs_per_month
           * avg_bytes_per_page
           * retry_multiplier
           / 1_000_000_000

Add a margin of 25 to 50 percent for debugging, schema changes and unexpected spikes. Debugging is real consumption and should be budgeted, not treated as waste.

Worked example

A weekly assortment check across 3,000 products:

• 3,000 items per run
• 1.2 pages per item on average, allowing for pagination
• 4 runs per month
• 800 KB per page (HTML and JSON only, assets blocked)
• 90 percent success rate, so a 1.11 multiplier

3000 * 1.2 * 4 * 800_000 * 1.11 / 1_000_000_000
= about 12.8 GB per month

With a 40 percent margin, plan for around 18 GB. That is a small monthly figure, and it is small specifically because assets were blocked. Remove that assumption and the same job can consume an order of magnitude more.

Cut consumption before you buy

Optimising usage is more valuable than shopping for a lower rate:

Block non-essential resources. Images, video, fonts and analytics are usually the majority of bytes and none of the data. Browser automation makes this a few lines of configuration, and we cover the approach in Playwright Scraping with Proxies.

Use the underlying JSON. A rendered page is often ten times the size of the API response that populates it. Finding it is the technique in Stop Scraping the Page, Find the API Instead.

Cache and revalidate. A conditional request that returns 304 costs a tiny fraction of a full download.

Fix parsers before scaling. Re-fetching pages because selectors are wrong is the most avoidable bandwidth spend there is.

Cap response sizes. Abort anything unexpectedly large, which also prevents accidental downloads.

Then choose the package

Once you have a monthly figure, look at the package tiers and price breaks. Stepping just over a boundary often lowers the effective rate, so it is worth checking whether a slightly larger package is cheaper per gigabyte than a smaller one plus overage. The pricing structure is explained in How Much Do Proxy Services Cost, and current package sizes are on the residential page.

Buy small first. Run the job for a week, compare actual consumption with your forecast, and adjust. Real numbers beat any estimate, including this method.

Verifying along the way

While you measure, confirm the connection is doing what you think. The proxy checker reports the exit IP and added latency, and IP lookup confirms the location, which matters if your job depends on regional targeting. For the general framework behind these numbers, see What Is Proxy Bandwidth.