Should You Leave Rollup? 964ms vs 246ms

On a 501-file ESM tree (197,380 bytes of source), Rollup 4.64.0 took a median 964 ms to produce one ES bundle. Rolldown 1.2.12 took 246 ms on the same machine, about 3.9x faster. Same entry, interleaved warm CLI runs, no minify.

Short answer: leave Rollup for Rolldown when library or app bundle time is the pain and you can live without a Rollup plugin that Rolldown does not yet match. Keep Rollup when a plugin, output option, or CI contract still assumes classic Rollup. No affiliate links in this post.

What I tested

• Machine: 8 vCPU Intel Xeon / 15 GB RAM Linux cloud box, Node 20.19.2, tested 5 Oct 2026 (about 23:00 to 23:10 IST). Shared box; tools interleaved each round.
• Fixture: 500 generated ESM modules plus a barrel src/index.js (501 files, 197,380 bytes). Modules form a shallow import chain and re-export from the barrel.
• Tools: rollup 4.64.0 CLI (src/index.js -o dist-rollup.js -f es --silent); rolldown 1.2.12 CLI (src/index.js -o dist-rolldown.js -f esm). Timed via direct node on each package bin (no npx wrapper).
• Timing: one warmup each, then five interleaved warm runs. Median wall-clock of the full CLI call.
• Output bytes: Rollup 126,894 B; Rolldown 130,522 B (about 3% larger on this fixture).
• One surprise: Rolldown was about 3.9x faster, but the Rolldown bundle was larger, not smaller, so speed alone is not a ship-size win.
• Not tested: tree-shaking quality on a real app, code-splitting / multi-chunk apps, Rollup plugin compatibility matrix, TypeScript input, sourcemaps, watch mode, minify paths, Windows/macOS, Vite's own Rolldown integration.

Is Rolldown faster than Rollup?

Tool	Median	Runs (ms)	Output bytes
Rolldown 1.2.12	246 ms	226 / 247 / 225 / 311 / 246	130,522
Rollup 4.64.0	964 ms	964 / 959 / 913 / 973 / 980	126,894

On this fixture Rolldown finished about 3.9x faster. Byte totals were close, with Rollup slightly smaller. The leave-Rollup case is strongest when a single-file ES build still costs near a second in CI and your plugin set already works on Rolldown.

If your pain is transform or minify rather than graph bundling, the SWC vs esbuild vs Babel post and the Terser vs esbuild vs SWC minify post are the sibling decisions on this site. Bundler choice for apps is covered in the Rspack vs Webpack post.

What do you lose leaving Rollup?

Rollup's plugin ecosystem and long-stable output options are still the safe default for many library builds. A plugin that only ships a Rollup 3/4 plugin API, or a CI script that asserts exact Rollup chunk names, can block a switch even when the CLI is faster.

Also re-check output size and tree-shaking on your own entry points. Here Rolldown was faster and about 3% larger; your app may flip that. Re-time with the same entry, format, and external list before rewriting the release job.

Should you leave Rollup for Rolldown?

Situation	My pick
Single-file ES/CJS library build still near a second in CI	Try Rolldown; measure your entry the same way
Already on Vite and waiting for its Rolldown path	Follow Vite's rollout; do not dual-maintain two bundlers
Depends on a Rollup-only plugin or exact chunk contract	Keep Rollup until that plugin ships Rolldown support
Need the smallest possible ship bytes on this fixture style	Re-measure; Rollup was slightly smaller here
First PR would only change the bundler binary	Fine to trial Rolldown behind a flag

Bottom line: on 501 files, Rollup took 964 ms and Rolldown took 246 ms. Who should not switch yet: teams blocked on a Rollup-only plugin or an output contract Rolldown does not match. Everyone else still paying near a second for a simple ES bundle should measure their own entry the same way.

How this was made: I generated the fixture, ran interleaved Rollup and Rolldown CLI builds on the ShopperCove test box, and kept the timing JSON; the write-up was drafted with AI help and checked against that output.

Sources

• 01rolldown.rshttps://rolldown.rs/
• 02github.com/rolldown/rolldown
• 03rollupjs.orghttps://rollupjs.org/
• 04npmjs.com/package/rolldown
• 05npmjs.com/package/rollup
• 06vite.devhttps://vite.dev/

Related

• 01shoppercove.com/blog/vite-8-3-2-renderbuilturl-bundled-dev-sourcemaps-october-2026
• 02shoppercove.com/blog/vite-plus-1-0-unified-toolchain-october-2026
• 03shoppercove.com/blog/webpack-5-111-esm-output-stable-september-2026
• 04shoppercove.com/blog/pnpm-vs-npm-vs-bun
• 05shoppercove.com/blog/turborepo-2-11-7-sdkroot-oidc-cache-october-2026