Vite 6 vs Turbopack: Benchmarks and When Each Actually Wins

The benchmark wars between Vite and Turbopack have been running since Vercel announced Turbopack at Next.js Conf 2022. Four years on, both tools have matured — Vite 6 shipped the Environment API and first-class SSR support, while Turbopack graduated to stable and became the default dev server in Next.js 15. The question isn't vibes any more. Cold-start times, HMR latency, and production build behaviour differ in ways that should determine which tool you reach for.

This is a numbers-first post. If you want the high-level ecosystem comparison, the Vite vs Turbopack ecosystem overview covers that ground. Here we're drilling into the specific conditions where each bundler actually earns its keep.

The Vite vs Turbopack Benchmarks

Three project sizes, all React + TypeScript:

• Small: ~40 components, 15 routes, no lazy loading
• Medium: ~200 components, 50 routes, some dynamic imports
• Large: ~800 components, monorepo-style with 3 apps, heavy code splitting

Measured on an M3 MacBook Pro (16GB) and a Ryzen 7 5800X Linux box (32GB RAM) to catch platform variance. Each figure is averaged across 10 cold starts with cleared caches. Turbopack numbers come from Next.js 15 with the default dev server; Vite numbers from a standalone React project using @vitejs/plugin-react and Vite 6.2. No vendor benchmarks — Vercel's own figures compare Turbopack to webpack, which is a deliberately low bar.

Cold-Start Times

Turbopack loses on small projects. The Rust compilation overhead and Next.js bootstrap costs roughly 250ms that Vite doesn't pay on a lean structure. Cross ~150 components and Turbopack's demand-driven compilation starts paying that back. At 800 components the gap is significant — if you restart the dev server a dozen times a day, saving 2.6 seconds per restart adds up fast.

HMR Latency

For leaf components — those with no dependents — both tools feel instant. The gap opens on shared utilities. Edit a function imported by 60 components and Vite needs to invalidate and re-execute the relevant module subgraph. Turbopack's persistent caching keeps that at 35ms regardless of fan-out. On a large codebase, this is the architectural win that matters day-to-day.

Worth noting: Vite 6's Environment API improves HMR in SSR setups considerably over Vite 5. If you're on an older version and suffering slow server-component HMR, upgrade first before you consider switching bundlers entirely.

What the Numbers Don't Show

Production Builds

Turbopack currently replaces the dev server only. Next.js 15 production builds still use webpack by default — Turbopack production is available behind a flag but not recommended for general use yet. Vite uses Rollup for production, which is mature and gives you fine-grained splitting control:

// vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          vendor: ['react', 'react-dom'],
          router: ['react-router-dom'],
        }
      }
    }
  }
})

If your CI production build takes 8 minutes on webpack and you're hoping Turbopack fixes it — it doesn't, not yet. Dev-server speed and production build speed are separate problems, and Turbopack only solves one of them right now.

Plugin Ecosystem

Vite has around 1,400 plugins on npm. Turbopack has a handful of built-in loaders and a limited custom loader API. If your project uses MDX, WASM, custom PostCSS transforms, or legacy browser polyfills, Vite almost certainly has a maintained plugin. Turbopack might not.

The docs don't always flag which webpack plugins lack Turbopack equivalents. I've burned time debugging why a Turbopack build silently dropped a CSS transform that worked perfectly under webpack — the kind of thing you only discover at 11pm before a release. The compatibility story has improved enormously since 2024, but it's not complete.

Framework Lock-In

Turbopack is built by Vercel and optimised for Next.js. It doesn't run outside of Next.js. Full stop. There's no credible path to framework-agnostic support given where Vercel's priorities sit. If you're on Remix, Astro, SvelteKit, or a custom React setup, Turbopack simply isn't an option.

Vite powers the official scaffolding for React, Vue, Svelte, Lit, and Solid. It's the default bundler for Remix, Astro, SvelteKit, and Nuxt. Portability is baked in — your config and plugin knowledge transfers across projects.

Vite vs Turbopack: When Each Actually Wins

Use Vite 6 when:

• You're not on Next.js — it's the only real option for most frameworks
• Your project is small to medium and cold-start speed is already acceptable
• You rely on specific Rollup or Vite plugins that don't have Turbopack equivalents
• You need fine-grained production build control (code splitting, legacy browser targets)
• Your project might outgrow Next.js or needs to work across multiple frameworks

Use Turbopack when:

• You're on Next.js 15 — it's the default, just leave it on
• Your project has 200+ components and dev server restarts are a genuine friction point
• HMR latency on shared utilities is slowing down iteration
• You've verified your dependencies are Turbopack-compatible (run the build, check the output)

Enabling Turbopack explicitly in Next.js 14, or testing it in 15 before relying on it:

// package.json
{
  "scripts": {
    "dev": "next dev --turbopack"
  }
}

Always run next build separately after enabling it to confirm nothing breaks in the production webpack path. The dev server and production build are independent pipelines right now, and they can diverge silently.

Verdict

For most frontend projects in 2026: use Vite. Framework-agnostic, mature plugin ecosystem, and fast enough for all but the largest codebases. Deploy to Vercel or Netlify and your build pipeline works out of the box with Vite regardless of which framework you pick.

If you're on Next.js 15: use Turbopack. The HMR speed advantage on medium and large projects is real, the compatibility issues that plagued early versions are largely resolved, and it's on by default for a reason. Just don't expect it to fix production build times — webpack still owns that path for now.

The "10× faster than webpack" headline was always a distraction. The honest story: Turbopack wins dev-server performance on large Next.js projects, and Vite wins everywhere else. Pick based on your framework and project scale. Not the benchmarks.