JS Bundler Benchmarks 2026: Is Rolldown Ready to Beat ESBuild and Webpack?
This year we have decided to re-test the results from 2025.
As in the previous year, all benchmarks were run under the
same controlled conditions. We used a single machine with identical hardware
and software configurations for each test, keeping tool versions fixed to
avoid version-related performance differences. Each bundler compiled the
same minimal React project containing only one index.jsx file, ensuring
that the benchmark focused on bundler overhead rather than application
complexity. Every test was executed 10 times, and we calculated averages
to reduce the impact of random system fluctuations. While this setup provides
a clear comparison, it’s important to note some limitations: we did not
measure warm-cache performance, advanced configurations, or cross-platform
differences such as Windows or macOS environments.
TL;DR – 2026 Benchmark Winners:
- Absolute Fastest: ESBuild (0.19s execution time) and Rolldown (0.27s).
- Lightest on Dependencies: ESBuild (1 dependency) and Rolldown/Rollup (2 dependencies). Webpack still ships with 26.
- Key Takeaway: While ESBuild dominates raw speed, Rust-based bundlers like Rolldown and RSPack are rapidly catching up, offering better Webpack ecosystem compatibility without the massive CPU overhead.
Read below for the complete RAM, CPU, and cold-build execution metrics across 8 different bundlers.
Test Environment & Setup
We reused the same React project but now we will bundle it using:
- Webpack (version 5.105.4)
- Rollup (version 4.48.0)
- ESBuild (version 0.27.3)
- Farm (version 1.6.7)
- Rolldown (version 1.0.0-rc.6)
- Snowpack (version 3.8.8)
- Parcel (version 2.16.4)
- RSPack (version 1.7.6)
System Configuration
- OS: Linux ArchHost 6.18.13-arch1-1
- Node.js: v22.14.0
- Cores: 16
- RAM: 16 GB (2 × 8 GB)
Benchmark Command
This benchmark measures cold build performance, meaning no previous cache or build artifacts were used. Many modern bundlers such as Webpack, RSPack, and Parcel heavily optimize incremental builds, so their performance during development may differ significantly from these results.
We used /usr/bin/time -v to measure peak RAM usage and CPU
load during the bundling process:
for i in {1..10}; do
/usr/bin/time -v yarn build:esbuild 2>&1 | awk ' # replaced with corresponding bundler
/Maximum resident set size/ {ram=$6/1024}
/Elapsed \(wall clock\) time/ {seconds=$0; sub(/.*: /,"",seconds)}
/Percent of CPU this job got/ {cpu=$0; sub(/.*: /,"",cpu)}
END {printf "Peak RAM: %.2f MB\nCPU Load: %s\nSeconds: %s\n", ram, cpu, seconds}'
done
Bundler Performance Results
RAM Performance
| I | II | III | IV | V | VI | VII | VIII | IX | X | |
|---|---|---|---|---|---|---|---|---|---|---|
| ESBuild v0.27.3 | 70.45 MB | 69.91 MB | 69.48 MB | 69.95 MB | 69.72 MB | 69.75 MB | 69.32 MB | 69.69 MB | 70.08 MB | 69.00 MB |
| Webpack v5.105.4 | 276.52 MB | 274.02 MB | 277.04 MB | 274.40 MB | 274.80 MB | 275.27 MB | 274.68 MB | 278.59 MB | 274.01 MB | 272.69 MB |
| Rollup v4.48.0 | 357.73 MB | 362.33 MB | 367.27 MB | 381.02 MB | 357.71 MB | 427.97 MB | 360.65 MB | 360.67 MB | 417.84 MB | 417.89 MB |
| Rolldown v1.0.0-rc.6 | 175.20 MB | 167.57 MB | 167.23 MB | 168.74 MB | 173.33 MB | 171.36 MB | 169.12 MB | 166.23 MB | 166.34 MB | 178.21 MB |
| Farm v1.6.7 | 250.58 MB | 249.99 MB | 250.42 MB | 255.43 MB | 255.07 MB | 284.44 MB | 250.88 MB | 261.84 MB | 257.49 MB | 254.38 MB |
| Snowpack v3.8.8 | 1118.01 MB | 1135.81 MB | 1073.27 MB | 1096.96 MB | 975.15 MB | 1070.26 MB | 1135.87 MB | 1061.93 MB | 1216.10 MB | 1063.56 MB |
| Parcel v2.16.4 | 277.23 MB | 299.34 MB | 299.88 MB | 300.23 MB | 301.37 MB | 299.62 MB | 300.39 MB | 300.01 MB | 300.21 MB | 301.19 MB |
| RSPack v1.7.6 | 387.02 MB | 393.48 MB | 393.72 MB | 390.38 MB | 384.49 MB | 395.74 MB | 401.41 MB | 393.58 MB | 388.91 MB | 390.15 MB |
CPU Performance
| I | II | III | IV | V | VI | VII | VIII | IX | X | |
|---|---|---|---|---|---|---|---|---|---|---|
| ESBuild v0.27.3 | 117% | 117% | 116% | 117% | 117% | 116% | 117% | 117% | 116% | 116% |
| Webpack v5.105.4 | 172% | 186% | 185% | 185% | 185% | 186% | 187% | 186% | 184% | 186% |
| Rollup v4.48.0 | 204% | 206% | 205% | 205% | 204% | 203% | 208% | 207% | 206% | 206% |
| Rolldown v1.0.0-rc.6 | 106% | 128% | 126% | 125% | 125% | 128% | 124% | 125% | 126% | 128% |
| Farm v1.6.7 | 144% | 149% | 148% | 146% | 148% | 142% | 147% | 146% | 148% | 146% |
| Snowpack v3.8.8 | 162% | 175% | 168% | 166% | 163% | 167% | 174% | 158% | 170% | 157% |
| Parcel v2.16.4 | 202% | 209% | 208% | 208% | 210% | 209% | 212% | 207% | 208% | 209% |
| RSPack v1.7.6 | 151% | 192% | 191% | 183% | 192% | 192% | 192% | 191% | 193% | 192% |
Now, the question is - why some of the results for CPU are showing more than 100%. The reason is that in Linux it shows the cores. When it reaches more than 100% - that means, that the process is using 2 cores, when it reaches more than 200 - then process is using 3 cores and so on. As we can see, Rollup and Parcel are requiring much more cores for their runtime, which is due to their architecture, and plain JavaScript implementation. ESBuild is written in Go, RSPack and Rolldown are written in Rust, which is visible on the usage of the cores.
Execution time (in seconds)
| I | II | III | IV | V | VI | VII | VIII | IX | X | |
|---|---|---|---|---|---|---|---|---|---|---|
| ESBuild v0.27.3 | 0.20 | 0.19 | 0.20 | 0.19 | 0.19 | 0.20 | 0.19 | 0.19 | 0.19 | 0.19 |
| Webpack v5.105.4 | 2.04 | 1.97 | 1.96 | 1.97 | 1.96 | 1.96 | 2.00 | 1.98 | 1.97 | 2.03 |
| Rollup v4.48.0 | 4.47 | 4.42 | 4.41 | 4.44 | 4.43 | 4.42 | 4.45 | 4.47 | 4.40 | 4.43 |
| Rolldown v1.0.0-rc.6 | 0.27 | 0.27 | 0.27 | 0.27 | 0.27 | 0.28 | 0.28 | 0.28 | 0.28 | 0.27 |
| Farm v1.6.7 | 0.78 | 0.76 | 0.77 | 0.77 | 0.78 | 0.77 | 0.77 | 0.76 | 0.77 | 0.79 |
| Snowpack v3.8.8 | 7.37 | 7.41 | 7.30 | 7.12 | 7.13 | 7.03 | 7.02 | 7.33 | 7.20 | 6.85 |
| Parcel v2.16.4 | 0.72 | 0.72 | 0.71 | 0.72 | 0.74 | 0.75 | 0.75 | 0.75 | 0.75 | 0.75 |
| RSPack v1.7.6 | 1.57 | 1.56 | 1.56 | 1.58 | 1.58 | 1.59 | 1.58 | 1.57 | 1.57 | 1.59 |
Security of the packages & traceability
As with any open source solution, every time that you or your company is depending from public libraries,
you need to understand the risks that it brings. One of such risks is the fact that with the big amount of the
packages you expose yourself to a bigger vector of attacks, such as typosquatting.
Also, when you have a lot of dependencies, you need to make sure that you use the latest patched version, to reduce the risks towards
zero-day vulnerabilities. In order to check that, let us see the situation with dependencies for the bundlers that we have mentioned
previously.
Dependencies will be counted in yarn.lock as in the following screenshot, meaning we will count only the 1st-level children:
Dependencies downloaded
| Bundler | Dependencies |
|---|---|
| ESBuild v0.27.3 | 1 |
| Webpack v5.105.4 | 26 |
| Rollup v4.48.0 | 2 |
| Rolldown v1.0.0-rc.6 | 2 |
| Farm v1.04 (cli + core) | 31 |
| Snowpack v3.8.8 | 53 |
| Parcel v2.16.4 | 15 |
| RSPack v1.7.6 (cli+core) | 7 |
Also, those packages are usually occupying disk space of your device. Let us look in the table of
the memory used on disk. We will measure the total amount of the packages installed in an empty folder
by running yarn add <name-of-bundler>, where <name-of-bundler will be changed to the ones mentioned previously
| Bundler | Size |
|---|---|
| ESBuild v0.27.3 | 11M |
| Webpack v5.105.4 | 29M |
| Rollup v4.48.0 | 6.8M |
| Rolldown v1.0.0-rc.6 | 41M |
| Farm v1.04 (cli + core) | 183M |
| Snowpack v3.8.8 | 58M |
| Parcel v2.16.4 | 217M |
| RSPack v1.7.6 (cli+core) | 151M |
Average Benchmark Results: 2026
Now, based from the previous results let's calculate the average for the bundlers and compare them with the 2025 results:
| Bundler | RAM 2026 | CPU 2026 | Execution Time (seconds) 2026 | RAM 2025 | CPU 2025 |
|---|---|---|---|---|---|
| ESBuild | 62.76M | 117% | 0.19 | 91.79M | 117% |
| Webpack | 219.88M | 184% | 1.98 | 294.35M | 187% |
| Rollup | 381.11M | 205% | 4.43 | 392.81M | 212% |
| Rolldown | 170.33 | 112% | 0.27 | ||
| Farm | 257.05M | 146% | 0.77 | 235.96M | 149% |
| Snowpack | 1094.69M | 166% | 7.18 | ||
| Parcel | 297.95M | 208% | 0.74 | ||
| RSPack | 391.89 | 187% | 1.58 |
Running the test locally
You can find the project on Github Run the following commands:
git clone https://github.com/FallenAngel97/bundlers-comparison
cd bundlers-comparison
yarn install
# run the commands for benchmarks noted at the top with /usr/bin/time
Results
Although ESBuild shows the best performance in this benchmark, Webpack still dominates the ecosystem due to its mature plugin architecture and large community.
Newer bundlers such as Rolldown and RSPack are rapidly gaining adoption because they aim to provide Webpack compatibility with Rust-level performance.
Also, we can see that Snowpack is standing a bit differently with it's results. It's due to it's philosophy. Snowpack, contrary to webpack, is providing you the possibility to run the application unbundled. This means, faster local development, because your dependencies are not changing. As we can see during the build, this is exacly the reason why it's performing differently to it's competitors. It is processing each dependency and converts it to the browser-compatible module, so that your browser can cache dependencies and optimize the bandwidth
Background photo by Homa Appliances on Unsplash