Rsbuild vs Vite for React: Build Time and Bundle Size Benchmark

Summary

This benchmark compares Rsbuild and Vite using two near-identical React apps and the same benchmark harness. I ran each benchmark five times on a Mac M1 Pro and report the median values for cold build time, repeat build after a small edit, and output bundle sizes. The goal is not a generic winner headline. The goal is practical: if your team is choosing a build tool, what should you expect in measurable terms and what trade-offs should you document before migrating?

"Rsbuild vs Vite" is usually discussed like a tribal debate, but most teams need a concrete question answered: Which one helps our specific app ship faster with fewer performance regressions and compliments the developer experience?

I wanted this comparison to be useful for real teams, so I used constraints that mirror production work:

• Shared React codebase and route map
• Same lazy-loading strategy
• Same image and asset set
• Equivalent minification and source map posture

If you need baseline context on previous Rsbuild optimization work, read my series: Part 1, Part 2, and Part 3.

How do you make this benchmark fair?

A fair benchmark controls for everything except the bundler/tooling runtime.

Test setup and parity notes

• React app with identical routes and component tree
• Shared dependency graph for UI, syntax highlighting, and animation
• Same production target assumptions
• Five runs per benchmark, median used for reporting
• Styling parity switched to Sass in both apps
• Bundler-specific Sass plugins used where required (@rsbuild/plugin-sass for Rsbuild; Vite Sass support via its pipeline)
• Entry file naming follows each tool's convention (src/index.tsx in Rsbuild app, src/main.tsx in Vite app)

Metrics collected

• Cold production build time
• Repeat production build time after a one-line source edit
• Output bundle size breakdown (js, css, images, total)

I used this benchmark harness:

npm run bench:cold:rsbuild
npm run bench:cold:vite
npm run bench:incremental:rsbuild
npm run bench:incremental:vite
npm run bench:size:rsbuild
npm run bench:size:vite

Each run appends JSON output to results/*.jsonl, which makes median calculations and table generation straightforward. Wanna run the benchmark yourself? Check out my repo

What did the real numbers show?

Environment:

• Machine: Mac M1 Pro
• Runs per test: 5
• Reporting statistic: Median

Visual comparison

Build timing results (median)

Raw medians were computed from these five-run sets:

• Rsbuild cold: 916.06, 621.58, 618.52, 621.12, 619.85
• Vite cold: 2233.22, 2075.28, 2071.94, 2036.29, 2085.48
• Rsbuild repeat-after-edit: 627.11, 623.53, 623.38, 615.33, 621.87
• Vite repeat-after-edit: 2071.97, 2092.31, 2075.36, 2041.47, 2059.85

One caveat: both tools showed a slower first run and tighter clustering afterward, so median was the right choice over mean.

Bundle size results

This is the key interpretation: size differences were small compared to timing differences. In this benchmark shape, throughput dominated.

Why was file count different if app code was similar?

The output structure differs by bundler strategy.

• Rsbuild emitted more split chunks across route and vendor boundaries.
• Vite emitted fewer files with a larger main JS payload in this run.

Neither is automatically better in all contexts. More chunks can help cache granularity but increase request orchestration. Fewer chunks can reduce request count but increase invalidation scope. You need real-user telemetry to choose the best split profile for your routes.

Where does Rsbuild usually win?

• Larger projects with heavier build workloads
• Teams already investing in Rspack-compatible optimization workflows
• Cases where build throughput becomes a repeated bottleneck in CI

If your team is managing large route trees and aggressively splitting bundles, Rsbuild can be a strong fit when combined with disciplined chunk strategy and lazy loading.

Where does Vite usually win?

• Teams prioritizing minimal config and plugin ecosystem familiarity
• Projects where dev startup experience is the main concern
• Teams with existing Vite operational knowledge and stable performance

Migration cost matters. A slightly faster build does not justify a switch if your current stack is stable, predictable, and productive.

What trade-offs should teams make explicit before migrating?

Decision framework you can actually use

Ask these questions in order:

1. Is build time currently a real bottleneck for delivery?
2. Do we have compatibility blockers to migration?
3. Are expected gains meaningful in CI, not just on one machine?
4. Do we have team capacity to absorb migration and stabilization?
5. Will this change reduce regressions or only satisfy curiosity?

If you cannot answer yes to 1 and 3, migration is probably not the highest-value work right now.

Recommended rollout pattern if you choose to migrate

• Run both build pipelines in parallel on a branch for one week
• Compare output artifacts and key route behavior
• Migrate internal docs and runbooks before merge
• Roll out behind a low-risk release window
• Track post-migration regressions for at least two sprint cycles

Avoid "big bang" switching with no fallback path.

Practical recommendation from this benchmark

If your current pain is build throughput, these results favor Rsbuild for this project profile by a wide margin on timing, with modest bundle-size advantage. If your current pain is ecosystem simplicity and your build times are already acceptable, Vite remains a practical choice.

That is the point of benchmarking with your own code: remove guesswork, then decide based on your bottleneck.

Related posts

• Optimizing bundle size with Rsbuild & Rspack: Part 1
• Optimizing bundle size with Rsbuild & Rspack: Part 2
• Tricky TypeScript Errors after pnpm migration

Final takeaway

Rsbuild and Vite are both capable. The winning choice depends on your bottlenecks, ecosystem constraints, and operational discipline. Benchmark with parity, evaluate in CI, and pick the tool that improves delivery outcomes over time, not the one with the loudest benchmark headline.