## TL;DR

Speed up systematically: measure where time goes, parallelize, split by speed, and delete waste (fixed sleeps, redundant setup). Aim for under 10 minutes for the blocking suite.

## Error

```text
(Not an error; a performance task. Symptom: the suite takes 30+ minutes and blocks merges.)
```

## Steps

1. Measure: time the suite and list the 20 slowest tests. Expected: the Pareto list.
2. Parallelize: workers/shards for unit, parallel runners for e2e. Expected: the biggest single win.
3. Split: fast unit suite blocks the PR; slow e2e runs post-merge or nightly. Expected: fast feedback preserved.
4. Remove waste: replace `sleep` with event waits, share setup with fixtures, drop redundant tests. Expected: minutes saved per run.
5. Re-measure and set a CI time budget with an alert. Expected: the suite stays fast.

## When to use

- Suite time blocks development.
- You need a systematic approach.

## When not to use

- One slow test (optimize that test).
- You can split instead of speeding up.

## Tool compatibility

- Any framework; parallel runners per framework.

## Variant phrasings

### Slow test suite optimization

The general task; measure-parallelize-split.

### Reduce CI test time

The CI framing; same techniques.

## Why it happens

Suites accrete tests and each adds time. Without active management, the suite grows past the feedback budget.

## Edge cases

- Parallelization exposes shared-state flakes; fix isolation first.
- Deleting tests is valid when they duplicate coverage.
- Time budgets need enforcement or they drift.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_l-82m2BknYltnhrMv4d2NQ