Turbopack vs Vite — Next.js's bet vs the indie favorite
Turbopack wins on HMR inside Next.js. Vite 8 wins on production builds and works everywhere else. Here are the numbers, the gotchas, and who should switch.
By Ethan
1,659 words · 9 min read
If you’re on Next.js, use Turbopack — it’s the default since Next.js 16, the HMR speed is real, and there’s nothing to migrate. If you’re on anything else, Vite 8 wins: faster production builds, broader plugin support, and no coupling to a single hosting platform. The “Vite to Turbopack” question is a trap — it’s a framework migration disguised as a bundler swap.
Who this is for
Developers starting a new Next.js project, or currently on Vite (Remix, SvelteKit, Astro, plain React) and wondering if Turbopack is worth evaluating. If you’re maintaining a Webpack-based project, that’s a separate comparison — Turbopack’s Webpack migration story exists but is out of scope here.
What we tested
- Turbopack: bundled with Next.js 16.2.6. Default bundler since Next.js 16 (October 2025).
- Vite: v8.0.10 (released March 12, 2026), now powered by Rolldown (Rust-based bundler replacing esbuild/Rollup under the hood).
- Test machine: M3 MacBook Pro.
- Test project: 800-component / 140-route / ~95k LOC TypeScript application. Large enough that “hello world” effects don’t dominate.
The tools in 30 seconds
Turbopack is Vercel’s Rust-based bundler, built specifically for Next.js. It handles server components, streaming, and the full Next.js dev/build pipeline. It’s not a general-purpose bundler — there is no “add Turbopack to Remix” path. If you want Turbopack, you’re on Next.js.
Vite is the framework-agnostic build tool that ate the dev tooling market over the last four years. Vite 8 replaces its esbuild/Rollup hybrid internals with Rolldown — a Rust port of Rollup — which closes the dev/production config-split problem and delivers Vite 7’s API with substantially faster build times on large projects.
Both tools use native Rust compilation as their core performance strategy. Both are fast. The gap is narrower than marketing suggests in either direction.
Turbopack vs Vite: Benchmarks
Numbers from our 800-component TypeScript project on M3:
| Metric | Turbopack (Next.js 16.2.6) | Vite 8 (Rolldown) |
|---|---|---|
| Cold dev start | 2.1s | 2.8s |
| HMR — deep component | 70ms | 130ms |
| Production build | 8.2s | 4.1s |
Three things to note before you screenshot this table:
Cold start: Turbopack’s 2.1s vs Vite’s 2.8s is a 25% gap. Real, but not life-changing for a project you start once per session.
HMR: 70ms vs 130ms is where Turbopack consistently earns its keep. Deep component changes — the ones that force propagation through 40+ dependent modules — land in under a frame on Turbopack. On Vite you’re just over two frames. Over hundreds of daily edits this adds up.
Production build: The 8.2s vs 4.1s comparison is not apples-to-apples. Turbopack’s build includes RSC server processing, streaming manifest generation, and Next.js’s full output pipeline. Vite is building a client bundle only. If you’re comparing pure bundle compilation time, the real gap is smaller — but the total wall-clock time you wait is what matters, and Vite 8 wins by 50% on this workload.
Vercel’s own published benchmarks show 2–5× faster builds and up to 10× faster Fast Refresh versus Webpack. That’s a different comparison. Turbopack’s advantage over Vite is 40–50% on HMR for deep components — not 10×. Quote the right number.
Vite 8’s Rolldown upgrade produced substantial real-world improvements versus Vite 7. Linear cut their build time from 46s to 6s. Beehiiv saw a 64% reduction. Ramp dropped 57%. These are not Vite vs Turbopack numbers — they’re Vite 8 vs Vite 7. The point is that Vite is not standing still.
Ecosystem
This is where the comparison diverges sharply.
Turbopack is Next.js-only and has deliberate compatibility gaps with the Webpack plugin ecosystem:
- Loaders are supported; plugins are not (and plugins must output JavaScript only).
@svgr/webpackdoesn’t work. If you use SVG imports as React components, you need a workaround.sassOptions.functionsis not supported.- Yarn PnP: not supported.
- URL imports: not supported.
- CSS ordering is different from Webpack — subtle visual bugs possible on migration.
- Bundle size regressions have been documented in production. Community migration reports in the Next.js discussion thread vary by project: one saw the shared chunk grow from 101 KB to 223 KB (+122 KB); another reported +48 KB on total first-load JS. Vercel has confirmed that
next buildreports inaccurate JS sizes under Turbopack; the real numbers are visible only in Lighthouse or browser devtools.
Vite has a mature plugin ecosystem built on Vite’s own API. Most major frameworks publish official Vite plugins. Plugin compatibility across Vite 7 to 8 is high — Rolldown uses the same plugin interface. Framework support: React, Svelte, SvelteKit, Vue, Nuxt, Astro, Remix, Qwik, and others maintain official integrations. RSC support is not Vite’s domain — that’s a Next.js feature, and if RSC is your reason for existing, you’re on Next.js.
For production deployments: Vite builds are static assets that deploy to any CDN, edge runtime, or platform. Vercel, Netlify, Cloudflare Pages, Railway, Render — all of them handle Vite output without configuration. Turbopack output is consumed by Next.js’s server infrastructure; Vercel is the natural deployment target, though Next.js runs on other platforms too.
Configuration
Turbopack configuration lives inside next.config.js or next.config.ts. The surface area is small by design — Turbopack intentionally exposes fewer knobs than Webpack. If your build requires custom loaders or specific Webpack plugin behavior, check the supported features list before committing. Several things that “just worked” in Webpack do not have a Turbopack equivalent today.
Vite configuration is explicit and well-documented. vite.config.ts covers build targets, aliases, SSR options, chunk splitting, and plugin configuration. The surface area is larger, but most projects only touch a few fields. Rolldown in Vite 8 is mostly transparent to the config layer — your existing vite.config.ts should work without changes.
If you enjoy configuring build tools, Vite gives you more to work with. If you want to not think about it, Turbopack’s defaults inside Next.js are reasonable.
Migration
Webpack → Turbopack (Next.js projects)
This is the migration path Vercel expects developers to take. As of Next.js 16, Turbopack is the default. If you have no custom Webpack plugins (only loaders), the migration is: remove webpack: (config) => config from your next.config.ts, test, done. If you have custom Webpack plugins, check each one against the supported list. Budget time for bundle size audits — the next build size reporter is unreliable under Turbopack; use Lighthouse.
If you’re evaluating Vite for a non-Next.js project and wondering whether Webpack is still the safer choice, our Vite vs Webpack migration guide covers the full migration calculus.
Vite → Turbopack
This is not a bundler migration. There is no path from a Vite project to Turbopack without switching to Next.js. If you’re on Vite + React (plain), switching to Next.js is a framework decision that affects routing, data fetching, SSR architecture, and deployment. The bundler underneath is downstream of that decision.
If you’re evaluating Next.js for its own merits and Turbopack comes along as a bonus — that’s a valid path. If you’re looking at Turbopack specifically and hoping to keep your existing setup, stop: it doesn’t work that way.
Vite 7 → Vite 8
This is the upgrade most Vite users will actually make in 2026. The Rolldown transition is mostly transparent. Vite 8 maintains API compatibility with Vite 7; most projects upgrade by bumping the package version and running the build. Plugin compatibility is high. The payoff is the build time improvements above.
Verdict
| Use case | Pick |
|---|---|
| New Next.js project | Turbopack — it’s already on, leave it |
| Existing Next.js + Webpack, no custom plugins | Turbopack — migration is low risk |
| Existing Next.js + heavy Webpack plugin usage | Turbopack with caution — audit gotchas first |
| React without Next.js (Vite + React Router, etc.) | Vite 8 — Turbopack isn’t an option |
| SvelteKit, Astro, Nuxt, Remix | Vite 8 — these frameworks run Vite; Turbopack is irrelevant |
| Large project where production build time matters | Vite 8 — 4.1s vs 8.2s at scale |
| Deep HMR-heavy development loop on Next.js | Turbopack — 70ms vs 130ms compounds over a long session |
Need @svgr/webpack or custom Webpack plugins | Webpack / Vite — Turbopack gaps apply |
The bottom line: Turbopack is the right call for Next.js. It delivers better HMR where it counts, and the migration from Webpack is manageable if you’re not leaning on plugins. Vite 8 is the right call for everything else, and the Rolldown upgrade makes the production build argument stronger than it was in Vite 7.
The only wrong choice is treating Turbopack as a drop-in alternative to Vite. It isn’t, and the framing costs people real investigation time.
Related reading
- Vite vs Webpack: when to migrate your project (2026)
- Next.js 16 vs React Router v7 — 2026 framework comparison
- Next.js vs Astro 2026 — when to choose static sites
Caveats
Bundle size regression: the bundle size figures cited above come from individual community reports in the Next.js discussions thread. Results vary significantly by project — both reports listed are from real migrations but represent single data points. Measure after switching, not before.
next build size reporting: Vercel confirmed this is broken under Turbopack. Check Lighthouse or the Network tab for real bundle sizes.
Affiliate disclosure: this article contains an affiliate link to Vercel’s platform (/go/vercel). We tested independently; the link doesn’t change the verdict.
Benchmark methodology: the 800-component project is one data point on one machine. Build times are sensitive to project structure, import graph depth, and cache warmth. The relative ordering (Turbopack faster HMR, Vite faster production build) has been consistent across community reports, but your numbers will differ.