Turbopack is Next.js's Rust-based successor to webpack, built by Vercel on the same turbo-tasks incremental computation engine that also powers Turborepo's task caching. It's been the default for next dev for a while now and it's genuinely good there — my dev server on a mid-sized Next.js app starts and hot-reloads noticeably faster than the old webpack dev server did. Production builds (next build --turbopack) are a different story: they work, but they haven't fully displaced webpack as the safe default for teams with complex custom webpack configs, and I'd rather be honest about that boundary than pretend it's uniformly solved.
The problem: webpack's compilation model doesn't scale with incremental edits
Webpack builds a dependency graph and, even with persistent caching, tends to redo more work than strictly necessary when a handful of files change deep in a large app. Turbopack's answer is a function-level incremental computation model borrowed from Turborepo: every unit of work (parsing a file, resolving a module, transforming an asset) is a memoized function call keyed on its inputs. Change one file, and only the functions whose inputs actually changed re-run — the rest of the cached call graph is reused. This is the same idea as React's memoization applied to the build pipeline itself, and it's why Turbopack's dev-server hot reloads stay fast even as a codebase grows, rather than degrading linearly with project size the way naive incremental webpack setups can.
# dev server — Turbopack is the default in recent Next.js versions
next dev
# production build with Turbopack (opt-in, check current Next.js docs
# for whether it's still flagged as beta for your specific setup)
next build --turbopackDev server maturity vs production build maturity
These are genuinely two different pieces of software wearing one name, and conflating them is the most common mistake I see in Turbopack discourse. The dev server's job is to serve unbundled or lightly-bundled modules fast and re-transform only what changed — a well-scoped problem that Turbopack has clearly solved. Production builds require whole-program optimizations: tree-shaking across the entire module graph, code-splitting decisions that affect every route's bundle size, minification, and compatibility with the long tail of webpack loaders and plugins that Next.js apps have accumulated over years. That surface area is much larger, which is why production build support has trailed the dev server by a meaningful margin.
If your next.config.js has a non-trivial webpack() override — custom loaders, SVG-as-component plugins, bundle analyzers — verify each one has a Turbopack equivalent before flipping the production build flag. Turbopack doesn't execute arbitrary webpack plugin code; it needs native support or a compatible shim, and coverage varies by plugin.
What it replaces from webpack, and what it doesn't yet
Turbopack replaces webpack's bundling, module resolution, and transform pipeline. It does not replace Babel or SWC as the underlying transform for JS/TS/JSX — Next.js already moved that to SWC (Rust-based) years before Turbopack existed, so Turbopack's speed win is specifically in the bundling and dependency-graph layer, not in re-parsing JavaScript faster than SWC already does. It's also not a general-purpose bundler you'd reach for outside Next.js the way you might reach for esbuild or Vite's Rollup-based production build — as of now it's developed in lockstep with Next.js and that's the primary place you'll encounter it.
Turborepo caches task outputs (build, test, lint) across a monorepo at the task level. Turbopack applies the same incremental-computation idea at the file/module level inside a single build. Same underlying turbo-tasks engine, different granularity, easy to conflate because of the shared name.
An honest read on where things stand
I don't have precise, current benchmark numbers I'd stand behind for 2026 specifically — bundler performance claims age fast and vary enormously by project shape, and I'd rather say that plainly than manufacture a percentage. What I can say from actually using it: the dev server switch is close to a free win for most Next.js App Router projects, worth trying by default. The production build switch is worth testing in a branch and comparing bundle sizes and build times against your existing webpack build before committing — not because it's broken, but because "mostly there" is a real category and it's worth verifying your specific dependency set lands in the "fully supported" bucket rather than the "still catching up" one.
Wrapping up
Turbopack's core idea — treat compilation as a graph of memoized function calls instead of a monolithic bundle pass — is a legitimately better model than webpack's, and it shows most clearly in dev-server responsiveness on large projects. Production build parity is still the part I'd verify rather than assume, plugin by plugin, before flipping the switch on anything business-critical. Use the dev server today; pilot the production build in a low-stakes branch first.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.