Playwright BiDi Size Report: Protect Proxy Bandwidth Metrics from Header Overcounting

A Playwright issue opened on September 12, 2026 reports that request().sizes() can overstate responseBodySize when Chrome is driven through Playwright's experimental BiDi backend. In the reproduction, a 2,000-byte body was reported as 2,151 bytes. The issue author observed that the extra 151 bytes matched the comparison run's response-header size.

This is an open issue report, not a confirmed production-wide defect or a proxy failure. Its practical value is the warning: browser telemetry fields can change meaning across backends. Teams comparing residential proxy bandwidth, cost or extraction efficiency should not treat a single automation metric as ground truth.

Internal research source: Microsoft Playwright issue, “bidi reports transfer size as responseBodySize, so request().sizes() over-reports the body by the header size,” opened September 12, 2026.

What the report shows

The issue uses a deterministic 2,000-byte response. Chromium over CDP reports a 2,000-byte response body, while the BiDi Chrome project reports 2,151 bytes. It also describes similar overshoot for compressed and chunked responses.

The proposed explanation is that one protocol value is feeding both transfer-size and encoded-body-size fields, even though Playwright treats those concepts separately. The issue remains open, and the BiDi backend is explicitly described as experimental. Buyers should therefore validate the behavior in their exact Playwright build and browser channel.

Why proxy teams should care

Many proxy trials calculate cost per megabyte, bytes per successful page, compression savings or traffic anomalies from browser automation. If headers are included in a field labeled as body size, small responses are disproportionately affected. A 150-byte difference is minor for a large image but material for thousands of small API responses.

The distortion can also create false route comparisons. One route may produce larger cookies, cache metadata or diagnostic headers. If those bytes are counted as body payload only in one backend, the route appears less efficient even when the delivered representation is identical.

Build a controlled regression test

Host an authorized fixture that returns fixed bodies of several sizes: 0, 100, 2,000 and 100,000 bytes. Include stable headers, then repeat with one additional large response header. Test identity encoding, gzip and chunked delivery separately.

For every run, record:

playwright_version
browser_channel
network_backend
proxy_route_alias
status
declared_content_length
decoded_body_bytes
encoded_body_bytes
response_header_bytes
reported_response_body_size
reported_transfer_size
body_digest

Do not record proxy credentials, cookies, authorization values or private payloads.

Compare four evidence layers

First, verify the fixture's known body length and digest. Second, read the actual response body and count its decoded bytes. Third, capture automation-reported sizes. Fourth, compare with a controlled network capture or origin-side byte counters where authorized.

Run direct, proxy, CDP and BiDi paths with the same fixture. A difference that follows the backend is not automatically a proxy bandwidth problem. A difference that follows the route may indicate header, compression, cache or representation changes and needs separate analysis.

Use a header-delta challenge

Return the same body twice while adding a known header of controlled length to the second response. If responseBodySize increases by the header delta while the body digest and byte count remain unchanged, the metric is mixing layers.

Repeat the challenge across payload sizes. This makes the error easy to identify and shows how much it can bias cost estimates for small objects.

Keep three sizes distinct

• Decoded body bytes: bytes available to the application after content decoding.
• Encoded body bytes: bytes in the selected compressed representation.
• Transfer bytes: encoded body plus headers and protocol overhead defined by the measurement source.

Name dashboards and data fields explicitly. Never call all three “bandwidth” without documenting the layer. For proxy invoices, use the provider's billing definition and reconcile it against an independent controlled fixture.

Release checklist

• Pin Playwright version, browser channel and backend in every result.
• Test known bodies at multiple sizes.
• Add a controlled header delta without changing the body.
• Verify decoded and encoded digests where applicable.
• Separate direct and proxy runs.
• Compare CDP and BiDi rather than merging their values.
• Keep body, header and total transfer metrics in separate fields.
• Exclude credentials and private data from traces.
• Re-run after browser or Playwright upgrades.
• Base purchasing decisions on verified completed work, not one telemetry field.

FAQ

Does this mean BiDi always overcounts proxy traffic?

No. The report concerns a specific next-version Playwright build and experimental backend. Reproduce it in your own environment before drawing conclusions.

Is the proxy adding the extra bytes?

Not necessarily. In the reported reproduction, the mismatch is tied to telemetry mapping. A controlled direct-versus-proxy matrix is required to isolate route effects.

Which number should be used for proxy cost?

Use the provider's documented billing layer, then validate it with known payloads and independent counters. Keep decoded body, encoded body and total transfer values separate.

Should teams stop using request().sizes()?

No. Treat it as one evidence source, pin the backend and regression-test its semantics before using it for financial or capacity decisions.

Related 98IP guides

Use the proxy bandwidth cost estimation guide to model billable traffic. Pair this check with the gzip and Brotli integrity test and the Playwright keep-alive issue report.

Compliance note

Run traffic measurements only against systems and data you own or are authorized to test. Respect rate limits, privacy commitments and platform terms. Redact secrets from traces and do not use proxy testing to evade access controls.