How to reduce proxy bandwidth

When you use a custom proxy, the page document and all resources loaded by the page can consume proxy bandwidth. Images, videos, fonts, scripts, and other assets can use much more bandwidth than the initial HTML document.

The best optimization depends on whether each resource is necessary and whether it must use the proxy:

1. Block resources that do not affect the result.
2. Load required static resources directly when they do not need the proxy.
3. Avoid using a proxy for requests that succeed without one.
4. Cache repeated screenshots when possible.

Start with the largest requests

Check your proxy provider dashboard or capture a representative request to find the hostnames consuming the most bandwidth. CDN hostnames serving video, images, or fonts are often the largest contributors.

Change one hostname or resource type at a time and compare the resulting screenshot. A resource that is unnecessary for one page might be essential for another.

Bypass the proxy for selected hosts

Use proxy_bypass_hosts with the custom proxy option to load matching hostnames directly instead of through the proxy:

https://api.screenshotone.com/take?access_key=<your access key>&url=https://example.com&proxy=http://user:password@proxy.example.com:8080&proxy_bypass_hosts=cdn.example.com&proxy_bypass_hosts=cdn.*.screenshotone.com

You can specify proxy_bypass_hosts more than once. Each value must be a hostname pattern without a scheme, port, path, or query. Use an exact hostname such as cdn.example.com, or replace a complete hostname part with *, such as cdn.*.screenshotone.com.

Matching requests are not blocked. They are sent directly from the ScreenshotOne network, while other requests continue through your custom proxy. Do not include the main page hostname unless you intentionally want the page document itself to bypass the proxy.

Caution

Direct requests use the ScreenshotOne IP address and location instead of the proxy IP address and location. A CDN or authenticated session might behave differently when resources are loaded from different routes. Test the rendered result, and remove a hostname from the bypass list if required content does not load.

Block resources that are not needed

Blocking avoids loading a resource at all, so it saves more bandwidth than bypassing it. Use block_resources when an entire resource type is unnecessary:

block_resources=media&block_resources=font

Use block_requests when you know a specific hostname or URL pattern is unnecessary:

block_requests=analytics.example.com&block_requests=*ads.example.com*

ScreenshotOne also provides options such as block_ads, block_trackers, block_chats, block_socials, block_annoyances, and block_cookie_banners. Depending on the page, these options can block third-party requests or clean up the rendered result.

Be conservative when blocking document, stylesheet, script, xhr, or fetch resources. Blocking them can change the page layout or prevent the page from rendering.

Retry with a proxy only when it can help

If a page normally works without a proxy, request it directly first. Retry once with a proxy only for selected network, IP reputation, location, rate-limit, or routing failures. This avoids paying proxy bandwidth for successful requests that never needed a proxy.

If a render with proxy_bypass_hosts is incomplete, retry once with the same proxy but without the bypass option. Do not retry indefinitely, and do not assume that a failed direct resource will automatically fall back to the proxy.

See when to retry with a proxy for the error-by-error retry guidance.

Cache repeated screenshots

If you repeatedly request the same screenshot, use cache=true and an appropriate cache_ttl. A cache hit avoids a new browser render and therefore avoids loading the page through your proxy again.

Recommended order

For a practical optimization pass:

1. Measure which hostnames and resource types use the most bandwidth.
2. Block requests that do not affect the screenshot.
3. Bypass the proxy for required static-resource hosts that work over the direct route.
4. Render without a proxy first when the target does not always require one.
5. Cache repeated screenshots.
6. Keep a single fallback retry without bypassing for incomplete renders.

Only use proxies for pages you are allowed to access with automated tools. If you are setting up a custom proxy for the first time, read how to use proxies.