Vite 8 promised 10-30x faster builds, so I measured it

Vite 8 replaced Rollup and esbuild with Rolldown, a Rust bundler, and the announcement says builds get 10-30x faster. I switched this site over to see what that means for a build that isn’t a benchmark. The bundling step got 3.2x faster. The whole build got 0.7 seconds faster. Both numbers are real, and the gap between them is the useful part of this post.

What Rolldown replaces

Vite has always been two bundlers wearing one config. esbuild pre-bundles dependencies in dev, Rollup produces the production output, and every plugin author has to care about the seams between them. Rolldown replaces both with a single Rust bundler, built by VoidZero on top of the Oxc parser, and Vite 8 ships it as the default.

The 10-30x figure comes from comparing Rolldown to Rollup directly. The same announcement lists what real companies got, and those numbers are more modest: Linear went from 46 seconds to 6, Ramp cut 57%, Beehiiv 64%, Mercedes-Benz.io up to 38%. Still impressive, and already a long way short of 30x. I wanted to know what a small site gets.

Forcing it into an Astro 6 site

This blog runs on Astro 6, which pins vite as a direct dependency at ^7.3.2. There’s no supported way to run it on Vite 8; that arrives with Astro 7. pnpm doesn’t care about supported:

"pnpm": {
    "overrides": {
        "vite": "^8.0.0"
    }
}

Then pnpm install, and pnpm why vite to confirm nothing is still resolving the old version:

dependencies:
astro 6.4.6
├── vite 8.2.2
└─┬ vitefu 1.1.3
  └── vite 8.2.2 peer

I expected this to break. It built first time. The only complaint in the log was a deprecation warning from Astro’s own dev toolbar plugin, telling it to use optimizeDeps.rolldownOptions instead of optimizeDeps.esbuildOptions, which is a pointed way to find out esbuild is really gone. The output was identical to the Vite 7 build: same 76 files, same 2.5MB, and every page I spot-checked rendered correctly.

I did spend ten minutes convinced Rolldown had 404’d half the site, including the RSS feed. It hadn’t. My checks were hitting a stale dev server left over from an earlier run on the same port. Benchmarking is mostly this.

Measuring it honestly

The build I’m measuring is small: 43 pages from 13 posts, plus an RSS feed, a sitemap and 14 Open Graph images rendered at build time with satori and resvg. The machine is an M1 Pro with 16GB on mains power, Node 24.11.1, pnpm 10.

Five cold builds and five warm builds per bundler, first run discarded, medians reported. Cold means every cache Astro or Vite writes gets deleted first:

for i in 1 2 3 4 5; do
    rm -rf dist .astro node_modules/.astro node_modules/.vite
    /usr/bin/time -p pnpm build
done

The discard-the-first-run rule earned its keep immediately. The first build after a fresh install took 17.3 seconds, with each OG image taking around a second to render. Every build after that came in under 6, with the images at 250-340ms each. Nothing to do with the bundler; macOS hadn’t cached the font files yet. If I’d compared that first Vite 7 run against a warmed-up Vite 8 run, this post would have a much better headline and it would be wrong.

The other thing worth doing is reading the build log rather than only timing the command. Astro logs its vite bundling steps separately from static route generation, which is where those OG images get rendered. That split is what makes the result explainable.

The results

	Vite 7.3.5 (Rollup)	Vite 8.2.2 (Rolldown)
Cold build	7.34s	6.64s
Warm build	6.25s	6.07s
Server bundle step	765ms	238ms
Client bundle step	20ms	22ms
Static route generation	3.84s	3.79s
Dev server ready	2.04s	2.10s

The lines that matter, straight from the logs:

# Vite 7.3.5
[vite] ✓ built in 768ms
[vite] ✓ built in 20ms

# Vite 8.2.2
[vite] ✓ built in 237ms
[vite] ✓ built in 27ms

Rolldown is 3.2x faster at the part it’s responsible for. The dev server didn’t move, the warm build saved under 200 milliseconds, and the cold build saved 0.7 seconds. Every row is telling the same story: the bundler got dramatically faster and the build barely noticed.

Why a small site barely moves

Bundling is 11% of this build. The two vite steps together take 785ms of a 7.34 second cold build, and the other 89% is content syncing, page rendering and above all those 14 OG images, which make up most of the 3.8 seconds of static generation by themselves. Amdahl’s law does the rest: make the bundling step take zero time and this build gets at most 11% faster. That’s the ceiling. The 9.5% I measured is close to all of it, with the last stretch of the gap down to run-to-run noise.

The client bundle is 20ms in both columns because this site ships almost no JavaScript. There isn’t much for a Rust bundler to be heroic about. And satori doesn’t care which bundler invoked it.

This is the bit the headline can’t tell you. The multiplier only applies to the slice of your build that is actually bundling. For an app with thousands of modules and a heavy transform pipeline, that slice is most of the build. For a content site with build-time image generation, it’s a rounding error.

Where the multiplier actually lives

To give the claim a fairer fight, I generated the kind of project it was made for: a create-vite React scaffold with 2,000 generated components, all imported through a barrel file so nothing gets tree-shaken away. Three builds per config, timing vite build directly so TypeScript checking stays out of the numbers.

At 2,000 modules, Vite 7 bundled in 970ms and Vite 8 in 198ms. At 10,000 modules, 3.67 seconds against 892ms. So 4.9x and 4.1x. One wrinkle worth knowing: @vitejs/plugin-react 6 only works on Vite 8, so the Vite 7 runs use plugin-react 5. It’s really a comparison of the stack you had against the stack you get, which is what an upgrade means in practice anyway.

I couldn’t manufacture the headline number even with 10,000 modules. What I got was a consistent 4-5x on the bundling itself, which matches the shape of the real-world reports better than the benchmark does: the production apps in Vite’s own announcement cut 38-64%, not 96%.

Frameworks are absorbing the upgrade as they go. Astro 7 shipped Vite 8 in June, and Astro’s measurements across real sites came out at 15-61% faster builds, with astro.build itself going from 62.7 to 24.2 seconds. Those are sites with more pages, bigger bundles and less build-time image work than mine. That range is the honest expectation for a framework app.

Where I’d start

1. Read your build log before you believe any multiplier. Astro prints the vite steps on their own lines, and most frameworks log something similar. If bundling is 10% of your build, no bundler swap can save more than that 10%.
2. If you’re on a framework, take the upgrade rather than the override. My pnpm override worked, but it’s outside what Astro declares it supports, and I’ve reverted it on main. This site gets Rolldown when it gets Astro 7.
3. If you’re on plain Vite with a big module graph, switch now. 4-5x on the bundling step, measured on boring components with no config changes at all. That’s who this release is for.

The 0.7 seconds is real and I’ll take it. But the number I’m keeping from this experiment is 11%, because that’s the question worth asking about any tool that promises a multiplier: a multiplier of what?