Published 2026-04-10 | Updated 2026-04-10 | LoadStrike Editorial Team | Reviewed by Architecture Group
See how LoadStrike uses Playwright and Selenium browser journeys inside a transaction-aware load testing model.
Explain how browser journeys fit into LoadStrike scenarios and reporting.
Direct answer
When should browser journeys be in the load test?
Browser journeys belong in the load test when the user-visible workflow is part of the business outcome you actually need to validate. That includes flows where rendering, navigation, client waits, and downstream side effects shape whether the transaction felt complete under load.
LoadStrike documents Playwright and Selenium support for that model. Browser steps can live in the same scenario and report surface as API, queue, stream, and downstream service stages instead of being split into a separate tooling story.
The user problem
The browser is part of the workflow that matters, so backend-only timings leave out the path the user actually experiences.
Why it matters
Rendering delays, navigation waits, and downstream side effects triggered by the page flow can change whether the transaction felt complete under load.
Best-fit workloads
Where this workload usually needs transaction visibility
Checkout and payment flows
Keep the UI journey and the backend confirmation in the same report.
Onboarding and approval journeys
Measure multi-step browser paths that trigger async work after the user action.
Operational UI scenarios
Compare front-end waits with the API and service work they trigger behind the scenes.
Who this is for
Teams validating checkout, onboarding, approval, search, or operational UI journeys that still need to be read as part of a broader transaction.
Why endpoint-only testing breaks down here
API-only tests can show healthy ingress timings while the real browser path slows down because of rendering delays, waits, navigation issues, or downstream dependencies triggered by the page flow.
How LoadStrike fits
LoadStrike publishes browser/runtime docs for Playwright and Selenium and keeps those browser-driven stages inside the same scenario, threshold, and report model used for API and event-driven testing.
What to expect
Verified LoadStrike fit points
Public documentation covers both Playwright and Selenium browser/runtime support.
Browser steps can be named and measured as part of the same scenario.
Reports stay in the same HTML, CSV, TXT, and Markdown formats used elsewhere.
The runtime still works in self-hosted clustered execution where the environment includes the required browser dependencies.
Resources
Docs and examples
Start with the browser/runtime pages that already show how Playwright and Selenium fit into the product surface.
See how browser steps surface in the final artifacts.
Common questions
Common questions
Does LoadStrike document Playwright support?
Yes. The site includes a Playwright UI load guide that explains how Playwright-driven browser work fits into the same transaction-aware scenario model.
Does LoadStrike also document Selenium support?
Yes. The site also includes a Selenium UI load guide so teams can see the same browser-journey model with Selenium WebDriver.
Why keep browser work inside the same runtime?
Because the meaningful performance question is often the full workflow. Keeping browser steps in the same runtime makes it easier to compare front-end timing with API, queue, and downstream completion behavior in one report.
Related
Related documentation
Start with the implementation details that match this page.
