Developers will spend three days shaving 200ms off a build that runs on their local machine, then ship a bundle that takes 4 seconds to parse on a mid-tier Android phone.

We’ve created a false dichotomy: build time vs runtime. And we’re optimizing the wrong half.

The Tooling Arms Race

The last five years have been an explosion of build tooling:

• Vite replaced Webpack for “instant” dev servers
• esbuild and swc replaced Babel for faster transpilation
• Turbopack promised to replace everything for even more speed

And it worked. Builds are faster. HMR is near-instant. Dev experience improved.

But here’s the thing: none of that ships to users.

The Metrics That Don’t Matter

We celebrate:

• “Build time down to 1.2s!” (from 1.8s)
• “HMR in 50ms!” (from 200ms)
• “Cold start reduced by 300ms!” (on a MacBook Pro)

We ignore:

• First Contentful Paint: 3.8s (on 3G)
• Time to Interactive: 6.2s (on median hardware)
• Bundle size: 847KB gzipped (for a landing page)

Developer experience metrics became the metrics. User experience became secondary.

The Build-Run Split

Modern web development has two phases:

1. Build time — Local dev, CI/CD, tooling performance
2. Runtime — What users actually experience in production

The problem: we’ve professionalized build-time optimization and casualized runtime optimization.

What We Optimize

Build time:

• Milliseconds matter
• Tooling is scrutinized
• Benchmarks are published
• Alternatives are constantly evaluated

Runtime:

• “Good enough”
• Lighthouse score > 90 = ship it
• Bundle analysis is optional
• “Users can just upgrade their phones”

Why This Happened

Developer tooling is visible. You feel slow builds every time you save a file. HMR lag is annoying.

User performance is invisible — until you explicitly measure it. And measuring production performance is harder than running npm run build.

So we optimized what we could see.

The Real Cost

Fast builds don’t make slow apps faster. They make developers more productive at shipping slow apps.

You can iterate quickly, deploy often, and still deliver a garbage experience if you’re not measuring the right things.

What Actually Matters

Runtime optimization isn’t glamorous:

• Code splitting (annoying to set up)
• Lazy loading (requires rethinking component structure)
• Image optimization (manual work, or another tool)
• Bundle analysis (one more step in CI)
• Real user monitoring (costs money, adds complexity)

Build-time optimization is easy by comparison. Swap Webpack for Vite. Done. 10x faster builds.

Runtime optimization is architectural. It’s not a tool swap. It’s design decisions, discipline, and ongoing measurement.

The Fix

Stop treating build time as the goal. It’s a quality of life improvement, not a product improvement.

Optimize builds for developer sanity. Optimize runtime for users.

Measure both. Prioritize runtime.

If your build is 10 seconds but your app loads in 800ms, you’re winning. If your build is 800ms but your app takes 10 seconds to interactive, you’ve optimized the wrong thing.

Conclusion

Fast builds are great. I love Vite. I love esbuild. I’m not saying build tooling doesn’t matter.

I’m saying it matters less than we act like it does.

We’ve professionalized the wrong half of the equation. Time to flip it.

Spend three days optimizing your bundle. Your users will notice. Your build pipeline won’t care.