load testing

Load testing with the flows your users actually take.

Load test scripts drift away from the real app. CodeReviewer replays your recorded user journeys in real browsers, many at once, and shows how long each flow takes and where errors start.

performance · /dashboard

Budgets held on the real pages.

  • LCP1.2s
  • CLS0.02
  • INP180ms

Median of three throttled runs, signed in, with a budget alert the moment a change regresses it.

p95latency for every user flow
Real browsersnot synthetic request scripts
No scriptsreuses your recorded journeys
the problem

Most load tests measure an endpoint, not a user.

Hand-written load scripts hit a few API calls and miss what a real sign-in, search or checkout does.

Scripts break every time the UI changes, so nobody runs them until something is already slow.

Results come back as raw request counts that don't say which user journey got slow.

how it works

From trigger to result.

Record the flows

Use the journeys from your test suites or from scan planning. No load scripts to write.

Set the load

Choose how many virtual users run at once and how many times each flow repeats.

Run in real browsers

Every virtual user is a real browser session, so pages, scripts and APIs are exercised together.

Read the results

See flow latency percentiles, error rate and throughput, with the slowest flows listed first.

capabilities

What you get.

Real user journeys

Sign-in, search, checkout or any recorded flow, replayed end to end exactly as a user would take it.

Latency percentiles

p50, p90, p95 and p99 flow times, plus minimum, maximum and mean.

Errors and throughput

Error rate and completed flows per second, so you can see when the app starts to struggle.

Slowest flows first

A per-flow breakdown points straight at the journey that degrades under load.

Safe journeys only

Journeys that change data are never replayed under load, and load tests only run on verified domains.

In the same report

Load results sit next to security and performance findings in the consolidated report.

Why real browsers

A user who waits eight seconds for a dashboard doesn’t care which API call was slow. Replaying the whole journey in a browser measures what they actually feel: the page, its scripts and every call behind it. Because the flows come from your existing test suites or the scan planner, there are no separate load scripts to keep up to date.

faq

Questions, answered.

What is load testing?

Load testing runs many users through your app at the same time to see how response times and error rates change as traffic grows.

How is this different from a request-based load tool?

Request-based tools fire raw HTTP calls you script by hand. CodeReviewer runs whole user journeys in real browsers, so it measures what a person waits for, including the front end.

How much load can it generate?

It is built for realistic concurrency on key journeys, tens of browsers at once, rather than synthetic floods. For millions of requests per second, pair it with a dedicated traffic generator.

Can I load test my production site?

Only domains you have verified can be load tested. Journeys that change data are left out, but load still costs real capacity, so many teams test staging or run at quiet times.

Does it work for mobile apps?

Load testing currently covers web apps. Android apps are covered by real-device functional testing.

Find out how your app holds up before launch day.

Join the waitlist. Load tests on your verified domains are included in the 15-day free trial.