Playwright Load Testing: Browser, API and Web Vitals Timing

An API can respond promptly while a checkout page is still rendering the order confirmation. LoadStrike lets you run the browser journey as a named scenario step, so the test can end at the visible business outcome rather than the first response. That measurement is useful only when its boundary is clear.

This article separates three measurements that are often merged in browser performance testing: request duration, journey duration and page-quality metrics. It is written by the LoadStrike Team with AI assistance. The worked values below are illustrative and unexecuted; they are not benchmark or customer results.

Give each measurement a start and an end

Define the browser step as, for example, checkout-submit: start immediately before clicking Place order and end after the page confirms the order ID and expected state. Its duration includes the browser actions and waits executed inside that step. If context creation, login, page navigation or an intentional pause occurs inside the same step, those operations are part of the measurement too.

A separate API scenario measures the request boundary you implement. Timing the POST /orders request is different from timing a browser journey, and neither automatically measures processing that continues after the response. Collect server spans or a downstream completion event when that is the question.

LoadStrike runs your Playwright code inside the scenario model; it does not automatically turn every browser network request into a separate backend timing. Use explicit instrumentation and retain its time window before joining that evidence to a report.

• Browser journey: user action through the required visible confirmation.
• API request: the specified client request through its response.
• Downstream transaction: the defined source through the application completion evidence.
• Page quality: the browser metric supplied by a collector, with its own observation window.

Read an illustrative checkout result without mixing clocks

Suppose one illustrative checkout sample records 240 ms for its order request and 1800 ms for click-to-confirmation. Those invented values explain measurement scope, not LoadStrike performance. Investigate the browser trace, other requests, rendering and any later processing before attributing the longer journey to the order API.

Do not subtract an API p95 from a journey p95 to calculate frontend cost. The percentiles may describe different observations and different boundaries. For a specific operation, retain its identifier and browser/network evidence so a reviewer can follow the same event.

Read completed journeys alongside failed or timed-out attempts. A lower duration percentile is not an improvement if more journeys stop before confirmation. Check the report's sample population and status distribution rather than assuming every latency statistic represents successful business completion.

• State which setup actions and waits are included in each named step.
• Compare the same application build, test data, browser version and workload.
• Retain failures and achieved invocations beside latency, rather than describing only the fastest completed subset.

Add browser Web Vitals as a separate quality check

A LoadStrike step duration is not Largest Contentful Paint, Interaction to Next Paint or Cumulative Layout Shift. The Browser Web Vitals helper accepts metrics from a browser collector and evaluates configured budgets. In the documented C# workflow, a callback supplies the result and the helper can normalize a Playwright performance snapshot.

Check that each required metric is actually present. A missing interaction measurement is not zero INP, and a page-load-only check does not demonstrate the experience of the interactions users perform later. Record when collection begins and ends, the tested interactions and the metric source.

Use a standalone check for a page-quality gate, or attach an intentional load profile when repeated checks are the requirement. These controlled measurements remain synthetic. Field Core Web Vitals describe real visits with varying devices, connections and session lifetimes; compare field data separately.

• Keep browser journey thresholds separate from page-metric budgets.
• State viewport, network/CPU emulation, cache state and browser version with a synthetic result.
• Use the linked Browser Web Vitals guide for collector and plan requirements; these helper checks require Pro or Enterprise.

Start with a browser smoke run, then add controlled pressure

First run one Playwright journey against an application you are authorized to test and verify its named outcome in the LoadStrike report. Launch the browser in WithInit, keep per-journey state isolated and release resources in WithClean or a finally block as described in the Playwright guide.

Browser sessions consume more generator capacity than protocol-only requests. Increase copies cautiously, monitor the generator and verify achieved work before deciding the application reached a limit. A configured arrival rate is not proof that the runner maintained it.

Use LoadStrike when you want the browser outcome, API workload and reviewed report in the same performance-testing workflow. Start with the linked Playwright guide and reports reference, then add the separate metric or completion check that answers your actual performance question.

• Confirm the journey succeeds at minimal load before collecting a comparison.
• Keep browser and API load profiles explicit; one browser journey can issue several requests.
• Record actual measurements only after execution, with repeats and the complete failure count.