Reduce Playwright Proxy Bandwidth: A Measured Test

For a product-data task, write down the required fields and an expected value on a fixture you control. For a screenshot, images and fonts may be part of the output and should stay enabled. Use a small, permitted test workload with the same destination and proxy settings for each run.

Save the browser and Playwright versions with the proxy session mode. Record failed requests and the provider meter readings for the test window. A challenge page, partial response or wrong locale can be smaller than a successful result. Count those as failures instead of reporting their smaller size as a saving.

Download the Playwright comparison script. It runs two fresh contexts against a URL you supply: one allows requests, and the other blocks images, media and fonts. Both install a request handler and block service workers, so the comparison uses the same interception settings. Set a selector and exact expected text for the output check.

The script can read PROXY_SERVER, PROXY_USERNAME and PROXY_PASSWORD from your process environment. Configure secrets through your local secret manager or a private shell session. It does not print request URLs, response bodies or proxy credentials. Without proxy settings, it measures a direct browser run.

Use route.request().resourceType() to choose the blocked types, as shown in Playwright’s network documentation. Do not block scripts or API requests just because they are large; they may produce the data you need. Adjust the downloaded set to your task.

Playwright documents that routing disables the HTTP cache. Adding routing only to the blocked run changes two conditions at once. The example installs a pass-through route in the baseline too, so both runs use routing.

Service workers can handle requests outside the ordinary routing path. The example uses serviceWorkers: "block" in both contexts. That makes the comparison easier to interpret, but it may change how an application behaves. If your workflow depends on a service worker or a warm cache, test that production configuration separately before adopting the change.

Request.sizes() exposes request and response body and header sizes. The example sums those fields for completed requests and counts failed, unfinished and unmeasured requests separately. The measurement ends after the page load and text check, with a timeout for each. Later background traffic falls outside that window.

These browser totals are diagnostic. They are not a complete accounting of proxy tunnel overhead, every failed transfer or the provider’s billing rules. Compare the provider meter over an isolated workload before forecasting spend. The bandwidth calculator can scale that measured usage by valid results.

We ran the example against a local fixture containing an image and a required text element. The baseline requested the image; the blocked run did not. Both preserved the expected text. Additional checks covered a wrong expected value and resource failures. These checks establish the example’s behavior on that fixture, not a savings percentage for a live website or a paid proxy route.

For your workload, alternate short baseline and blocked runs to reduce order effects. Use the same explicit completion condition, then compare valid output, failures and the full usage window. Keep the version and configuration with the result so a later site change can be investigated.

If you use a hosted browser, check the platform’s proxy integration guide before assuming that local launch options apply. For rate limits, use bounded retries and Retry-After; blocking assets does not change the destination’s access policy.