Why We Chose Turbopack (and What We Had to Change)

When we started this site, we reached for the Next.js default: webpack under the hood, familiar, predictable, well-documented. That choice served us well for a while. Then Turbopack stabilized enough to take seriously, and we started paying attention.

The promise is real. Turbopack is substantially faster on incremental builds. On a codebase our size, cold starts dropped by roughly 60% and hot reload latency went from noticeable to instant. For a team that lives in the development loop, that is not a minor improvement — it changes how you work.

But switching is not free.

Turbopack does not support all webpack plugins. If your next.config.js leans on webpack-specific configuration — custom loaders, plugin chains, manual chunk splitting — you will need to audit it.

In our case, the main casualty was our MDX setup. We were using @next/mdx, which requires a webpack loader configuration that Turbopack cannot execute. The fix was conceptually straightforward but required rethinking our content pipeline: instead of webpack-level MDX transformation, we moved to next-mdx-remote, which compiles MDX inside the server component render, not at build time.

The result is actually cleaner. MDX is now just a string that gets compiled on demand, not a special webpack artifact. The content pipeline is easier to reason about, and it works the same way in development and production.

The switch also surfaced configuration debt we had been ignoring. Several loaders in our next.config.js were doing things that Next.js now handles natively. Turbopack's stricter compatibility requirements forced us to clean those out.

This is probably the hidden benefit of a major tooling migration: it creates pressure to audit assumptions you have been coasting on. We removed roughly 40 lines of webpack configuration that had accumulated over time, most of which was working around problems that newer Next.js versions had already solved.

For us, yes. The developer experience improvement is genuine and immediate. The migration cost was bounded — a few days of careful audit and testing — and the resulting configuration is simpler than what we started with.

If you are on a webpack-heavy setup with extensive custom plugins, budget more time. But if your next.config.js is relatively standard, Turbopack is worth trying today.

We are building everything new on Turbopack from this point forward. The tooling is fast enough that we rarely think about it, which is exactly how it should be.