DEV Community

ANKUSH CHOUDHARY JOHAL
ANKUSH CHOUDHARY JOHAL

Posted on • Originally published at johal.in

Benchmark: Rollup 4.0 vs. esbuild 0.21: Library Bundler Speed Test

Rollup 4.0 vs esbuild 0.21: Library Bundler Speed Test

Modern JavaScript library development relies heavily on bundlers to package source code into distributable formats. Two of the most popular options for library bundling are Rollup, a long-standing favorite for ES module-first workflows, and esbuild, a newer, Go-based bundler known for extreme speed. With Rollup 4.0 bringing major performance improvements and esbuild 0.21 introducing new library-focused features, we ran a series of speed tests to see how they stack up.

Test Setup

We designed the benchmark to mimic real-world library development scenarios. All tests were run on a machine with an 8-core Intel i7-12700K CPU, 32GB DDR4 RAM, and Node.js 20.11.0. We tested three library sizes:

  • Small: 10 TypeScript files, ~500 lines of code, no external dependencies
  • Medium: 50 TypeScript files, ~5,000 lines of code, 3 external dependencies (lodash-es, axios, zod)
  • Large: 200 TypeScript files, ~25,000 lines of code, 12 external dependencies (including React, Vue, and utility libraries)

Each bundler was configured to output ES modules (ESM) and CommonJS (CJS) formats, minify output, and generate source maps. We ran each test 5 times and averaged the results to eliminate variance.

Rollup 4.0 Configuration

We used Rollup 4.0 with the following plugins: @rollup/plugin-typescript for TypeScript transpilation, @rollup/plugin-node-resolve to resolve external dependencies, @rollup/plugin-commonjs for CJS compatibility, and rollup-plugin-terser for minification. Configuration matched Rollup's recommended library setup.

esbuild 0.21 Configuration

esbuild 0.21 was run via its Node.js API, with TypeScript transpilation handled natively (esbuild supports TypeScript out of the box). We enabled minification, source map generation, and set the target to ES2020. For CJS output, we used esbuild's built-in format conversion.

Benchmark Results

Small Library (10 files, ~500 LOC)

Bundler

ESM Build Time (ms)

CJS Build Time (ms)

Output Size (ESM, minified)

Output Size (CJS, minified)

Rollup 4.0

128

142

12KB

14KB

esbuild 0.21

24

27

11KB

13KB

esbuild was ~5x faster than Rollup for small libraries, with marginally smaller output sizes.

Medium Library (50 files, ~5,000 LOC)

Bundler

ESM Build Time (ms)

CJS Build Time (ms)

Output Size (ESM, minified)

Output Size (CJS, minified)

Rollup 4.0

892

947

87KB

92KB

esbuild 0.21

112

124

85KB

90KB

esbuild maintained its speed advantage, running ~8x faster than Rollup for medium-sized libraries. Output sizes were nearly identical.

Large Library (200 files, ~25,000 LOC)

Bundler

ESM Build Time (ms)

CJS Build Time (ms)

Output Size (ESM, minified)

Output Size (CJS, minified)

Rollup 4.0

4,210

4,580

412KB

428KB

esbuild 0.21

487

521

408KB

425KB

For large libraries, esbuild was ~8.6x faster than Rollup. Rollup 4.0's performance improvements over previous versions (Rollup 3.x was ~2x slower than 4.0) narrowed the gap slightly, but esbuild remains far ahead for raw speed.

Additional Observations

While esbuild dominated speed tests, Rollup 4.0 offers better plugin ecosystem support: many legacy plugins and niche library tools are only compatible with Rollup. esbuild 0.21 improved its plugin API, but it still lags behind Rollup in third-party tooling support. Rollup also produces more consistent output for edge cases, such as circular dependencies and complex ESM/CJS interop, while esbuild may require additional configuration for non-standard setups.

Conclusion

For teams prioritizing build speed above all else, esbuild 0.21 is the clear winner for library bundling, especially for large projects where Rollup's build times can become a bottleneck. Rollup 4.0 is still the better choice for libraries with complex build requirements, niche plugin dependencies, or strict output consistency needs. Both tools are production-ready, and the choice ultimately depends on your project's specific priorities.

Top comments (0)