[Feature]: Expose recorded ResourceTiming on APIResponse (parity with Request.timing())

[shahzad31]

🚀 Feature Request

Browser-originated requests expose detailed network phase timings via Request.timing() (DNS, connect, TLS, TTFB, receive). Requests made through APIRequestContext (request.get/post/..., fetch) return an APIResponse that has no equivalent — the only way to get any timing today is to wall-clock the call in userland, which yields a single opaque total.

I'd like to propose exposing the per-phase ResourceTiming on APIResponse, read-only, mirroring Request.timing().

Why this is a thin change, not a new capability

Playwright already collects and maintains these exact timings for APIRequestContext — they were added in #32613 (merged) and recorded into the HAR/trace (the trace viewer already shows the duration), and proxy edge cases have since been fixed (#32855). So the data already exists in memory; this request is only to surface it through the public API instead of requiring users to parse trace/HAR artifacts.

A previous PR (#32647) implemented exactly this but was closed with the rationale that "Playwright isn't a network performance testing tool." Respectfully, I'd push back on two points:

1. This isn't about load/performance testing — it's diagnostic parity with browser requests, which already expose timing().
2. "Rough timings can be measured in userland" only holds for total time. The phase breakdown requires socket-level events (lookup / connect / secureConnect / response) on the connection Playwright owns inside fetch.ts, including redirect and proxy handling — userland has no access to it. feat(fetch): expose timings #32647 itself surfaced the SOCKS/HTTP-proxy connect timing bug fixed in fix(har timing): record connect timing for proxied connections #32855, which no userland wrapper could have measured correctly.

Example

const response = await request.get('https://api.example.com/orders');
console.log(response.timing());
// { startTime, domainLookupStart, domainLookupEnd, connectStart,
// secureConnectionStart, connectEnd, requestStart, responseStart, responseEnd }

The shape would be identical to Request.timing(), so there are no new concepts to learn. It could also be gated behind the existing omitTiming option to stay opt-out.

Motivation / use cases

• Debugging slow or flaky API tests in CI: knowing whether latency came from DNS, TLS handshake, or the server, instead of one aggregate number.
• Synthetic monitoring built on Playwright (e.g. Elastic Synthetics, Checkly) that runs browser and API checks side by side and needs consistent network fields across both. Downstream context: feat: multi step api runner elastic/synthetics#997.

Prior art / recurring demand

• [Question] Is there a way to return an api request response time? #19621 — "Is there a way to return an api request response time?" (👍 9); would have been closed by feat(fetch): expose timings #32647
• [Feature]: Add to APIResponse elapsed time and method name #34992 — "Add elapsed time and method name to APIResponse" (👍 3); closed as stale
• feat(fetch): expose timings #32647 — implemented APIResponse.timing(); closed unmerged
• feat(fetch): record timings #32613 — records these timings into HAR (merged) — the data source this proposal would expose
• [Feature] Allow accessing request body and headers when performing http request #16239 — access request headers/body/method on API requests (👍 33) — related "surface request/response internals" theme

Happy to help revive #32647 or open a fresh PR if the team is open to a read-only accessor over the already-recorded timings. Thanks for considering!

[dgozman]

Shahzad (@shahzad31) Could you please share one example of the usage for this feature? Not a one-line theoretical idea, but some actual code/feature/etc? The example "Synthetic monitoring built on Playwright" is exactly what we are cautious about - any monitoring built upon Playwright's api requests is limited by imperfections of our fetching, like never using http2/3 for example. We are not sure any reliable performance monitoring can be built here, so we'd like to not mislead our users.

[shahzad31]

i think this isn't an absolute performance benchmark timings, i mean i consider these mostly as diagnostic and relative in nature. let's say we have two API tests measuring some resource creation, if one degrees over time, we would like to diagnose those with relative values, On the same client over time, a jump in dns, tls, or ttfb is a real, actionable signal for what went wrong in testing.