Cutting Your CI Time in Half

A pipeline that takes twenty-five minutes turns every pull request into a context switch and tempts people to merge without waiting. Getting it under ten changes how the team works. Most of the time is in a few predictable places.

Cache the dependency install

Installing packages from scratch on every run is often the single biggest chunk. Cache the dependency directory keyed by the lock file, so it is restored in seconds when nothing changed and only rebuilt when the lock file does. Same idea for any build cache your tooling supports. This alone often removes several minutes.

Only build and test what changed

On a pull request, you mostly care about the code the pull request touched. Run the linter and the tests for the changed packages and their dependents, not the entire suite. Keep the full run for the main branch after merge, so nothing is missed, it just does not sit between the developer and their feedback.

Parallelise the slow stage

The test run is usually the longest step and usually easy to split: divide the tests across several machines that run at the same time. Going from one runner to four can turn twelve minutes into four. There is a limit, because each machine pays a fixed setup cost, so add runners until the total stops dropping and no further.

Run the fast checks first and fail early

Order the stages cheapest first: formatting and linting, then unit tests, then integration tests, then end to end. A formatting error should fail in thirty seconds, not after a fifteen minute end to end run. Let a failure stop the pipeline immediately rather than pushing on to report every problem.

Cut the end to end suite down

End to end tests are slow and valuable, and teams tend to accumulate dozens that overlap. Keep a small set that covers the flows you truly cannot ship broken, and move the rest of that coverage down to faster integration tests. A leaner end to end suite that people trust beats a large one they routinely rerun.

Watch the trend

Put the pipeline duration on a graph. It creeps up quietly as tests and steps are added, and a creeping number is easy to ignore until it is painful. Seeing the line lets you spend twenty minutes trimming when it starts climbing, rather than a day when it has become unbearable.

The reason it matters

CI is in the path of every change the team makes. Time taken off it is time given back on every pull request, every day, and a fast pipeline is one people actually wait for.

Common questions

Where does most CI time usually go?

Installing dependencies from scratch, running the whole test suite serially, and rebuilding things that did not change. All three are addressable.

Is it safe to only run tests for the changed code?

For pull request feedback, yes, if you also run the full suite on the main branch after merge. You get fast feedback and a full safety net, just not on the same run.

Does more parallelism always help?

Up to a point. Splitting tests across more machines helps until the fixed overhead per machine, mostly setup, outweighs the time saved. Measure to find your point.