Six thousand tests, a four-hour run, and a request to make it faster. This lecture is where the time goes and what can realistically be done about it.
Measure before optimising. A typical large Selenium suite spends its time roughly like this, and the proportions surprise people:
| Where | Typical share |
|---|---|
| Browser startup and teardown | 15-25% |
| Setup through the UI | 30-40% |
| Protocol round trips | 10-20% |
| Waiting for the application | 15-25% |
| The behaviour under test | 10-15% |
The thing you care about is the smallest slice. Everything above it is addressable.
Attack them in order of size.
Setup through the UI is usually the biggest. Creating records by filling forms. Move it to API calls, as in the intermediate track. This routinely halves a suite's runtime and is the single highest-value change available.
Browser startup is next. Reuse drivers per file with state reset between tests rather than a fresh browser per test. On a thousand tests this saves tens of minutes.
Protocol chattiness. Reuse element references. Batch reads with executeScript where you would otherwise make several calls. This matters far more on a remote Grid, where each call carries real network latency.
Application waiting. Partly outside your control. What is inside your control is not waiting longer than necessary: polling intervals tuned sensibly, and conditions that resolve as soon as the state is right rather than on a fixed schedule.
Then, and only then, parallelism. Parallelism multiplies whatever you have. Multiplying a badly built suite gives you a badly built suite running on more machines, at more cost.
The honest ceiling.
Selenium is slower than Cypress and Playwright, structurally, because of the protocol. No amount of tuning closes that gap. A senior engineer should be able to say so plainly, and also say what the gap buys: browser and language reach nothing else matches.
Realistic figures for a well-built suite, worth having in mind so you can set expectations:
- A well-optimised browser test: 3 to 8 seconds.
- With 30 parallel sessions: roughly 300 tests per minute.
- A 2,000-test suite: around 7 to 10 minutes on adequate infrastructure.
If your numbers are far worse, the cause is usually UI setup, insufficient parallelism, or an under-provisioned Grid rather than Selenium itself.
When you have hit the real ceiling, the remaining moves are not about speed:
Run fewer browser tests. Push detail down to API and unit tests. A validation rule checked in the browser costs seconds; the same rule checked at the API costs milliseconds. This is the largest remaining lever and it is a strategy change rather than an optimisation.
Tier the suite. Smoke on commit, core on pull request, full on merge, deep nightly.
Delete. A suite that grew for five years contains tests nobody can justify. Deleting them is legitimate engineering.
The cost conversation. At this scale infrastructure is a real budget line: Grid nodes or cloud sessions, CI minutes, and the engineering time to maintain them. Being able to say "this suite costs roughly this much per month, and here is what reducing it would cost in coverage" is a senior conversation that most automation engineers never have, and it is often what gets you the time to do the work properly.
Remember this: measure the breakdown first, fix UI setup before buying machines, and know the honest ceiling so you can set expectations.
Reference: Selenium best practices.