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.
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 public product surface.
See how browser steps surface in the final artifacts.
Common questions
Common questions
These questions are rendered on the page and mirrored in the matching FAQ structured data when the route is indexable.
Does LoadStrike publicly document Playwright support?
Yes. The public 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 public 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
Keep moving from positioning into concrete product detail.
