Vite 8's Rolldown Makes Builds 13x Faster, Not the Dev Server

Vite 8's Rolldown Makes Builds 13x Faster, Not the Dev Server

When a new version ships, I usually just type npm install and move on. But installing Vite 8 and looking inside node_modules made me stop for a second. The two names that had always been installed alongside Vite - rollup and esbuild - were gone entirely. In their place sat a single unfamiliar line: rolldown.

That's the heart of Vite 8 (stable release, March 2026). It usually gets summed up as "Vite got faster with Rust," but what actually happened is more specific - and more interesting - than that.

For years, Vite ran two separate engines: one for development and another for bundling production builds. Vite 8 merged them into a single Rust bundler called Rolldown. It's less an engine swap than a consolidation - where there used to be two vehicles, now there's one.

Here's the conclusion in one line: the speedup is real, but it lands on the "production build," not the "dev server." What you have to verify in exchange is the real subject of this post. With benchmarks var.gg built firsthand, I'll walk through what changed and what stayed the same.

[!NOTE]
Every measurement here comes from a representative Vite app freshly scaffolded on local Windows (Node v24). var.gg's own frontend runs on Next.js, not Vite, so this isn't a "we migrated our production app" story. Instead it's a reproducible benchmark: the same source tree placed on Vite 7 and Vite 8 in turn, compared on the same machine. So read the numbers as a direction, not a promise - on a large real-world app the multipliers can differ.

What Is Vite, and Why Did It Have Two Engines?

Let me start by unpacking the unfamiliar terms in plain language, for readers seeing them for the first time.

• Bundler: a tool that takes the dozens to thousands of scattered JS, CSS, and image files and packs them so the browser can fetch them quickly, stripping out unnecessary code along the way. Think of it as the person who packs your moving boxes efficiently.
• Vite: a tool that wraps that bundler together with the dev server and production build a frontend project needs, all in one package. It's the de facto starting point for React, Vue, and Svelte projects.
• HMR (Hot Module Replacement): when you edit and save code, it swaps only the changed part into the page instead of reloading the whole browser. It's what makes development feel fast.

One important fact here: a frontend toolchain has two jobs with opposite personalities.

The first is the job during development. The moment a developer saves, it has to respond instantly. It doesn't need to be perfectly optimized - it just has to be fast, period. Vite handed this job to esbuild (an ultra-fast transformer written in Go).

The second is the job at deployment time. The code you ship to real users has to be split into small pieces (code splitting), stripped of what it doesn't use (tree shaking), compressed, and given a debugging map (source maps). Here precision matters more than raw speed. Vite handed this job to Rollup (a JavaScript-based bundler with the most mature ecosystem of the bunch).

Here's the analogy. The old Vite was a restaurant with an ultra-fast prep counter for cooking during service (esbuild) and a separate, meticulous packing-and-logistics line for shipping (Rollup). It was a fast, sensible arrangement. But when the prep counter and the packing line play by different rules, you get headaches - the kind of bug where it worked fine in development but behaves differently once deployed. The same code runs through two different pipelines.

What Changed - Pinning Down "Old X → New Y" Exactly

Vite 8 rewrote those two lines as one family called Rolldown/Oxc. Let's separate the two names first.

• Rolldown: a bundler written in Rust. Its goal is "Rollup-compatible usage plus esbuild-class speed." It's the assembly line that bundles files and produces chunks.
• Oxc (JavaScript Oxidation Compiler): a suite of compiler tools written in Rust - a parser that reads JS/TS, a transformer, a minifier, and so on. It's the set of cutters, gauges, and quality inspectors.

Their relationship can be captured like this.

Diagram: this section is illustrated with a flowchart - view it in the original article on var.gg.

But here's a point you have to get exactly right. It's easy to smear over with a marketing one-liner, so I checked the official migration docs myself. Here's the conclusion.

The last row is the key one. The dev server did not switch to "bundling all your code up front the way a production build does." Vite's default dev server still runs on the model that leans on the browser's native ES modules, and the so-called "Full Bundle Mode" that pre-bundles everything is carved out as an experimental/future feature, not the default.

So it's wrong to write "Vite 8 unified development and deployment under a single bundler." The precise sentence is: "the internal substrate for bundling, transforming, and optimizing was consolidated onto Rolldown/Oxc." Why that distinction matters shows up as numbers in the benchmark shortly.

One more thing. Back in the Vite 7 era there was a separate rolldown-vite package for people who wanted to try rolldown early (an opt-in experimental build). In Vite 8 that's been folded into the main vite package itself. So a new project doesn't need to reach for rolldown-vite separately - just install Vite 8 and you're on the Rolldown path.

I Ran It Myself - Packages Vanished, the Build Got 13× Faster

From here on, these aren't estimates - they're results I verified firsthand. I took the same React app (a 24-component dashboard using the recharts chart library and lucide-react icons), placed it on just two versions - Vite 7.3.5 and Vite 8.0.16 - and measured on the same Windows machine.

(1) Two Engines Collapse Into One Binary

Look at node_modules/.bin right after install and the difference is right there.

• Vite 7 → .bin = { esbuild, rollup, vite } - packages installed: 107
• Vite 8 → .bin = { rolldown, vite } - packages installed: 62

esbuild and rollup are gone, leaving rolldown alone. Checking the dependencies on the npm registry tells the same story - vite@8.0.16 directly depends on a single package, rolldown, while vite@7 directly depends on both rollup and esbuild. As the platform-specific binary packages of the two engines merged into one Rolldown, the number of installed packages fell from 107 to 62.

(2) The Build Got ~13× Faster (Stable Across Repeated Runs)

How you read this matters. The 13–14× on the production build is a rock-solid number that doesn't wobble across repeated runs. What took Rollup about 2.2 seconds, Rolldown finishes in the 0.15-second range.

The dev server startup time, by contrast, is not a story. Depending on cache state, 8 was slower (cold) or faster (warm). It's just jitter within the same ballpark. And that's expected - the esbuild that backed the dev server was already plenty fast. Swapping in Rolldown left no room for the dev server to get dramatically faster in the first place. What sped up is the production build, where Rollup was the bottleneck. This meshes exactly with the point I stressed earlier - "the dev server model is unchanged." The 10× is real, but it lives behind the deploy button, not the save button.

(3) The 13× Isn't the Result of Skipping Work

Fast is meaningless if the output is flimsy. So I compared what the two builds produced.

Both produced a single bundle cleanly, and the sizes are nearly identical (Rolldown's is actually 2.3% smaller). It produced the same output 13× faster - it isn't fast because it skipped something.

Is "10–30×" Real? Only If You Keep the Conditions Attached

The official Vite 8 announcement headlines "10–30× faster builds than Rollup." It also cites real preview cases - one app's build dropping from 46 seconds to 6, that sort of figure. These numbers aren't false. But stripped of their conditions, they turn into an overstatement.

Look at the public Rolldown benchmark repo and the app under test is a massive module graph - think 10,000 JSX components plus 9,000 dependency modules. At that scale Rollup takes over 100 seconds, while Rolldown finishes in the low single-digit seconds. The "10–30×" comes precisely from that large graph, and specifically from the production build.

Our benchmark was a mere 24-component app and still showed 13× on the build. If anything, that's good evidence that the build gap is real even on small apps. That said, on an even smaller app - an empty template - other bottlenecks like tsc type checking, plugin overhead, the Windows file watcher, and antivirus loom larger, so you might not see 13×.

The honest sentence is: the bigger the app, the bigger the gain, and promising a flat 30× on an empty template is an overstatement.

So Does Anything Break? "Mostly Works" Isn't "Works Without Checking"

You swapped out the entire bundler - will all your existing plugins just keep running? This is where the real cost of migration hides.

Rolldown is designed to be compatible with Rollup's plugin API. So most Vite plugins work as-is. But the official docs' phrasing is "almost fully compatible." The "almost" is the crux.

One signal I checked myself: the official React plugin already got a major version bump.

• @vitejs/plugin-react@5.x → peer: vite ^4|5|6|7 (Rollup/esbuild world)
• @vitejs/plugin-react@6.x → peer: vite ^8 (depends on @rolldown/plugin-babel)

In other words, moving to Vite 8 means bumping the React plugin from 5 to 6 as well, and internally the babel wiring switches to a Rolldown-native plugin. It's no guarantee that "every Rollup plugin works without changing a single character."

[!WARNING]
Representative items to run through a migration checklist before upgrading Vite 7 → 8 (per the official migration guide):

• build.rollupOptions → build.rolldownOptions - the name changed (the old one is deprecated).
• The object form of manualChunks is unsupported - if you've built a vendor-chunk splitting strategy, it may break.
• Some Rollup hooks are unsupported (shouldTransformCachedModule, resolveImportMeta, and others) - plugins that finely control advanced caching, asset URLs, or dynamic imports need checking.
• The system / amd output formats are unsupported, and plugin-legacy's transpilation down to ES5 or below is unsupported - hold off if your app must support very old browsers.
• CJS interop and minifier output differ - the Oxc minifier and the esbuild minifier make different assumptions, so the compressed result isn't byte-for-byte identical. Visual regression tests are recommended.

To sum up: on compatibility, "mostly works" is the right characterization. But that's different from "safe to upgrade without checking." The more plugin-dependent your app, the more that gap comes back as cost.

There's one less-obvious trade-off here. Measuring the disk myself: the package count dropped (107 → 62), but the single Rust binary was heavier. Rolldown's binary at ~23MB plus Lightning CSS at ~10MB is larger than the old esbuild's 11MB plus Rollup's 5MB (the official announcement itself notes that install size grew by ~15MB). Fewer packages doesn't mean a smaller disk footprint - you trade for speed, but the binary got bigger.

Should You Migrate Now? Conclusions by Situation

In the face of a big tooling shift, the answer is always "it depends." Broken down concretely:

That last row is where var.gg sits. Our frontend is Next.js, so this post isn't a record of "migrating our app." The reason I ran this verification anyway is the larger current of core JS-ecosystem tools being rewritten in native languages (Rust/Go). It's an event of exactly the same character as when I recently benchmarked the TypeScript compiler's native rewrite firsthand - instead of trusting the marketing copy, you run it yourself on a safe copy and confirm "what actually changes in our case." What a new tool absorbs and what it leaves untouched is something you can only really settle by getting hands-on with each beta or new release and running it yourself.

Wrapping Up - Not "Fast Because Rust" but "The Internal Contract Changed"

To restate the heart of Vite 8 in one line: it's not "fast because Rust." It's that Vite rewrote the dual-engine structure it had long maintained - esbuild for development plus Rollup for deployment - around Rolldown/Oxc. The biggest promise of that shift isn't only speed; it's shrinking the difference in how modules are handled between development and deployment, inheriting as much of the Rollup plugin ecosystem as possible, and moving the internal implementation to Rust.

And running it myself gives a more honest picture than the marketing. The build was 13× faster even on a small app; the dev server, already fast, stayed roughly the same; and plugins "mostly" work, but a major version