A slow pipeline is not an inconvenience. It is a tax on every engineer, every day, and it compounds: slow feedback encourages larger changes, larger changes make builds slower, and eventually people start batching work to avoid the pain.
Before optimising anything, measure. Record wall-clock time from commit to first useful signal, and again from commit to deployable artifact. Those two numbers usually tell you which of the five common causes you are dealing with.
1. Cold caches
The single most common cause of a slow pipeline is rebuilding dependencies that have not changed. If every job re-downloads the same packages, you are paying that cost hundreds of times a day.
Fix: key your cache on the lockfile hash, restore it before install, and share it across jobs that need the same dependencies. This alone often cuts build time in half.
2. Sequential jobs that should be parallel
If tests, linting, and type-checking run one after another, you are waiting for their sum instead of their maximum. Split them into parallel jobs that begin together.
The constraint is not CPU — it is usually the number of available runners. Increasing runner concurrency is often cheaper than paying engineers to wait.
3. Tests that depend on the full world
Integration tests that boot every service are valuable but slow. Test sharding lets you split a suite across many runners, and a test-impact analysis lets you run only what a change can affect.
Start with sharding, because it is mechanical and safe. Add impact analysis only after you trust your test suite’s isolation.
4. Rebuilding what did not change
Monorepo pipelines frequently rebuild services untouched by a change. Detect affected packages from the diff and skip the rest. The savings scale with repository size, which is exactly when CI pain is worst.
5. No feedback hierarchy
A pipeline that tells you the build failed after twelve minutes of tests has the order wrong. Run the fastest, highest-signal checks first — formatting, lint, type-check — so obvious failures surface in seconds.
The goal is not a fast pipeline. It is a short time from mistake to discovery.
Measuring whether it worked
Track four numbers before and after any optimisation: median build duration, P95 build duration, cache hit rate, and queue wait time. Queue wait is the one teams forget, and it is often larger than the build itself.
Report these in a dashboard engineers can see. A pipeline improvement nobody can observe is a pipeline improvement nobody will defend when someone proposes adding another twelve-minute step.
How long should this take?
For a typical application pipeline, the highest-value fixes — caching, parallelism, and feedback ordering — take about a week to implement and validate. Teams commonly see build time fall by 50–70% and, more importantly, a first signal arriving in minutes rather than tens of minutes.
Start with the measurement. You cannot fix what you have not quantified.