LoadStrike /Browser load testing
See how LoadStrike uses Playwright and Selenium browser journeys inside a transaction-aware load testing model.
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 Playwright-driven journeys are modeled in LoadStrike.
See the matching Selenium workflow guidance.
Read a longer guide to treating the browser as part of the transaction.
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.
Use this guide when Playwright browser journeys should run inside the same LoadStrike scenario and reporting model.
Use this guide when Selenium browser journeys should run inside the same LoadStrike transaction and reporting model.
This page explains how to read a LoadStrike report. Use it when you want to know what each section means and where to look first.
Related
Related comparisons
Use these comparison pages if you still need a tool-level decision.
Compare LoadStrike and k6 for APIs, Kafka, browser tests and async completion, including correlation requirements, extensions and hosting tradeoffs.
Compare LoadStrike and Locust by Python test authoring, master/worker and Kubernetes execution, completion evidence and reporting requirements.
Related
Related integrations
Connect the run output to the observability backend your team already uses.
See how the LoadStrike Datadog sink fits into transaction-aware, self-hosted load testing workflows.
See how the LoadStrike Splunk HEC sink fits into transaction-aware reporting workflows.
Related
Next steps
Keep moving with the most relevant follow-up pages.
Connect browser work with downstream completion.
Return to the broader business-workflow model.
Open the docs and sample-reference entry points that help browser-heavy teams start faster.
Next step
Next step
Start with your browser runtime, then decide which journey stages belong in the report.
