How we cut build times in half without changing the stack

As our engineering team grew and our codebase expanded, we started noticing a creeping frustration among developers. What used to be a snappy feedback loop had slowly degraded into a tedious wait. CI pipelines were taking over 40 minutes, and local dev builds were pushing the five-minute mark.

The immediate reaction from the team was natural: we need to rip out our current bundler and migrate to the shiny new native tools everyone is talking about. But migrating a massive, legacy-entangled monolithic frontend is rarely a quick win.

Start by measuring, not guessing

Before touching a single line of our configuration, we instituted a brief pause. We needed to understand exactly where the time was going. We instrumented our build processes with detailed telemetry and profiling plugins to capture a granular breakdown of the pipeline.

The biggest bottleneck wasn't our tooling—it was our assumptions about what those tools were actually doing under the hood.

The results were illuminating. We discovered that nearly 40% of our build time was being consumed by generating source maps for heavily duplicated third-party dependencies that rarely changed. Additionally, a legacy image optimization step was running synchronously on every single local hot-reload.

By implementing aggressive caching for vendor modules, deferring heavy optimizations to production builds only, and pruning dead dependencies, we saw an immediate and drastic reduction. We successfully halved our CI times and brought local builds back under a minute, all while keeping our existing stack intact.