End-to-end testing

Your test suite is too slow for one of two reasons

Either the runner is slow, or you cannot tune the runner. Almost every guide on this fixes the first and quietly assumes the second away. This one covers both.

Matthew Diakonov, Written with AI

Published June 15, 20267 min read

Run it on your own app

Direct answer

To speed up a slow end-to-end suite: run tests in parallel across workers and split them across CI shards, reuse authenticated state instead of logging in inside every test, and cut redundant UI tests that re-check logic a faster test already covers. The catch the rest of the internet skips: all three are properties of the runner, so they only work if you own it.

Parallelism and sharding references below are verified against the Playwright parallelism docs (checked 2026-06-15).

Lever 1: parallelism, the one that pays the most

A serial suite is a single browser doing one thing at a time while the other CPU cores sit idle. The fix is two layers: workers (parallelism inside one machine) and shards (splitting the run across several machines). Playwright runs test files in parallel across worker processes by default, and the --shard flag splits a run across CI jobs that each take a slice.

The math is mechanical. Four shards, each running a quarter of the suite on its own runner, finishes in roughly a quarter of the wall-clock time. The example below splits a 48-scenario run across four CI jobs.

ci: 4 parallel jobs

This only exists if you can run the command. With Assrt that is the normal mode: each #Case in your plan runs as an independent scenario, so a large plan splits cleanly across parallel CI jobs the same way. Nothing about the run is hidden behind a vendor API.

Lever 2: stop logging in 47 times

Logging in through the UI is one of the slowest things a browser can do, and most suites repeat it at the top of every test. Authenticate once, save the session to a state file, and load it everywhere else. Playwright supports this directly through storageState. The pattern looks like this:

playwright.config.ts

If a single login takes five seconds and you have forty tests, this one change removes more than three minutes of pure waiting from every run. Assrt scenarios reuse the same idea through seeded sessions, so a flow behind auth does not pay the login tax on every scenario either.

Lever 3: cut the tests that earn nothing

Slow suites accumulate duplicate coverage. A browser test that re-verifies a calculation an API test already proves is pure overhead: it adds minutes and finds nothing the faster test would miss. Two honest cuts:

Push logic down the pyramid. If a behavior can be asserted at the API or unit layer, test it there. Reserve browser tests for the flows that only break in a real browser.
Delete accidental overlap. When two end-to-end tests walk the same path to assert the same thing, keep one. The other is wall-clock you pay on every push for no extra signal.

A quieter source of slowness lives next door to this one: flaky tests that pass on a retry. Every retry is a full re-run, so a 10% flake rate is a 10% tax on a green build. If your slowness is really flakiness, the fix is different. We wrote that up in headless Chrome test flakiness and in self-healing selectors and maintenance hours.

The cause most guides will not name

Read back through the three levers. Every one of them is a knob on the runner: workers, shards, the config file, what runs on push versus nightly, which auth state loads where. The common advice on this assumes you can reach all of those knobs. A large group of teams cannot, because they handed their tests to a managed QA cloud that runs them on someone else's infrastructure.

When that suite is slow, you do not edit a config. You file a ticket. The runner is opaque on purpose, and the pricing reflects the convenience: these services commonly run several thousand dollars a month. The speed of your tests becomes a vendor's internal decision, not yours.

Who controls the speed knobs

Same three levers. The difference is whether you can reach them.

Feature	Rented QA cloud	Assrt (tests you own)
Where tests execute	Vendor cloud you cannot see into	Your CI. `assrt run --plan-file tests.txt --json`
Parallel workers and sharding	Whatever the vendor chose; not your call	Yours. Each #Case is an independent scenario you split across jobs
Reused auth / seeded session	Hidden behind the platform	Seeded sessions you control, no login tax per scenario
When the suite is slow	Open a support ticket and wait	Tune the run yourself, today
Cost	Commonly several thousand dollars a month	$0. Open source.

A managed cloud buys you not running your own infrastructure. The trade is exactly the runner control this page is about.

What Assrt does to stay out of your way

An AI-driven runner has its own speed risk: if a model has to interpret every step, that interpretation can become the bottleneck. Assrt's answer is in the defaults. The agent that reads your #Case steps and drives the browser runs on Claude Haiku (claude-haiku-4-5-20251001) by default, the fastest and cheapest tier, chosen so interpretation does not slow the run down. If a specific suite needs heavier reasoning, you override it with --model; otherwise the default is tuned for throughput.

And because the run reports through --json to stdout, your pipeline consumes the result like any other test step. There is no dashboard you have to log into to find out whether the build is green. The whole thing is in your repo and your CI, which is the only place the speed knobs live.

You can read the runner for yourself: it is open source at github.com/assrt-ai/assrt-mcp. Start a run with one command:

terminal

Suite slow and you are not sure which cause it is?

Bring your CI timing and we will find whether it is the runner, the auth tax, or flakiness on retry, and what to change first.

Questions teams ask about slow suites

Frequently asked questions

What is the single biggest win for a slow E2E suite?

Parallelism. Most end-to-end suites run serially by default, so a 47-test suite waits on one browser doing one thing at a time. Turning on parallel workers and splitting the run across CI shards cuts wall-clock time roughly in proportion to the number of workers and machines you give it. Playwright runs files in parallel across workers out of the box and exposes a --shard flag for splitting across machines.

Why does reusing authenticated state speed things up so much?

Logging in through the UI is one of the slowest things a browser test can do: it loads a page, fills a form, waits for a redirect, and waits for the dashboard to settle, often 3 to 8 seconds, and most suites repeat it at the start of every single test. Authenticating once in a setup step, saving the cookies and local storage to a storageState file, and loading that file in every test removes that repeated cost across the whole suite.

Should I delete UI tests to make the suite faster?

Delete the redundant ones, not the load-bearing ones. A UI test that re-checks logic already covered by a fast API or unit test is pure overhead. But the flows that only break in a real browser (a checkout, an auth redirect, a multi-step form) are exactly what end-to-end coverage is for. The goal is fewer, higher-value browser tests, not zero.

How does owning the test code affect speed?

Every speed lever (parallel workers, sharding across machines, reused auth state, project filtering, choosing what runs on every push versus nightly) is a property of the runner. If your tests live in a closed SaaS that runs them on its own infrastructure, you cannot reach those levers. When the suite is slow, your only option is to file a ticket. When the test code and the runner are yours, you tune it yourself.

What does Assrt actually hand me, and where does it run?

Assrt runs test scenarios you write in a plain #Case format and reports structured pass/fail with screenshots and video. It runs locally and in your CI: `assrt run --plan-file tests.txt --json` emits a JSON report to stdout for your pipeline to consume. Each #Case runs as an independent scenario, so you can split a large plan across parallel CI jobs. Nothing is locked to a vendor cloud.

Does an AI-driven test runner add latency per test?

It can, which is why the default model matters. Assrt defaults to Claude Haiku (claude-haiku-4-5-20251001), the fastest and cheapest tier, specifically so step interpretation is not the bottleneck. You can override the model with --model if a particular suite needs more reasoning, but the default is tuned for throughput.

Is Assrt free?

Yes. Assrt is open source and free. The competitive context here is real: managed QA clouds run from several thousand dollars a month, and the trade you make for that price is exactly the runner control this page is about.

More on keeping the tests themselves cheap to run and read: readable Playwright test code.