Why your CI is slow, and what actually fixes it

Slow continuous integration is treated as an infrastructure annoyance. It is really a behavioural problem: once a pipeline takes twenty minutes, people batch changes to avoid waiting, and batched changes are harder to review and riskier to deploy.

Measure before optimising

Most pipelines have one dominant stage, and it is frequently not the one people assume. Before changing anything, get a breakdown by step across several runs.

The common distribution is dependency installation and test startup dominating, with the actual build and tests a minority of the time.

Cache the right things

• The dependency store, keyed on the lockfile hash — not the installed folder, which is slower to restore than to recreate.
• Build artefacts and framework caches, keyed on source and config.
• Docker layers, with the dependency install above the source copy so a code change does not invalidate it.

A cache keyed too broadly never hits; one keyed too narrowly is never reused. The lockfile hash is almost always the right key for dependencies.

Run independent work in parallel

Linting, type-checking and tests rarely depend on each other. Running them as parallel jobs turns the total into the longest one rather than the sum.

Test suites themselves usually parallelise across workers, and this is often the single largest win available on a mature codebase.

Do less on every commit

Not everything needs to run on every push. A fast path on each commit — lint, types, unit tests — with slower work such as end-to-end suites running on pull requests or before deploy keeps the feedback loop short without losing coverage.

In a monorepo, run only what the changed files affect. This is more work to set up and it is the difference between a pipeline that scales and one that gets worse every quarter.

How fast should CI actually be?

As a working target, under five minutes for the feedback a developer waits on, and under fifteen for the full pipeline including deployment. Past roughly ten minutes people stop waiting, start context-switching, and begin batching changes — which is the real cost, and it is much larger than the compute bill.

Is paying for faster runners worth it?

Often, yes, and the arithmetic is usually one-sided. Compare the monthly cost of larger runners against the hourly cost of the engineers waiting on them. A team of five waiting an extra ten minutes several times a day is spending far more than the upgrade costs — though it is worth caching properly first, since that is free and frequently larger. The same arithmetic applies to team cost generally, which our in-house vs agency calculator makes explicit.