Vite 8 and Rolldown: What Actually Changes for React Apps

Vite 8 is a significant release for React teams, but probably not in the way most people expect.

It will not automatically improve your Largest Contentful Paint. It will not shrink a 500KB chart library, fix an overloaded main thread, or make a slow third-party script go away. Your users do not care which bundler produced the JavaScript — they care how fast it loads and responds.

What Vite 8 does is change the build pipeline. It moves Vite onto Rolldown, a Rust-based bundler built by the VoidZero team, with the production build path being the most immediate place React teams will notice it. That makes this less of a typical major version bump and more of a build-machinery swap. For teams where CI build time is a real cost — or where production builds are painful enough that developers avoid running them locally — this is the release to test.

The right question is not just "is Vite 8 faster?" It is: does upgrading make this React app faster to build without changing what we ship to users in a bad way?

What you need to know upfront

• Production builds can get significantly faster. Vite cites 10–30x faster bundling in benchmarks vs Rollup, with real-world examples from Linear (46s → 6s), Ramp (−57%), and Beehiiv (−64%).
• This is build performance, not automatic Core Web Vitals improvement. INP, LCP, CLS, and JavaScript bundle size still need separate measurement.
• Most small-to-medium React apps can test the upgrade directly. Apps with heavy Rollup config, custom plugins, library mode, monorepos, or SSR should move more carefully.
• The React plugin changed. @vitejs/plugin-react v6 uses Oxc for React Refresh and removes Babel from the default path.
• Benchmark before and after. Capture build time, output sizes, chunk counts, and a Lighthouse run before calling the migration done.

Vite 7 vs Vite 8: what changed under the hood

Vite's original architecture split work between two separate tools:

That two-tool split — esbuild for dev, Rollup for prod — was a deliberate pragmatic choice. esbuild is very fast but lacks some of Rollup's plugin ecosystem and tree-shaking sophistication. Rollup is thorough but written in JavaScript, which caps its speed.

Rolldown is designed to close that gap: native-speed bundling with a Rollup-compatible plugin API. Over time it also aims to unify the dev and production transform paths, which should reduce the class of "works in dev, breaks in prod" edge cases.

How much faster is Vite 8 in practice?

The numbers Vite cites in their announcement are from the Rolldown beta and preview period, not from a controlled lab:

• Linear: 46s → 6s production build
• Ramp: 57% reduction
• Mercedes-Benz.io: up to 38% reduction
• Beehiiv: 64% reduction

These are real companies with large apps, and the gains are big enough to pay attention to. But the specific win for any given project depends on:

• total module count
• number of routes and code-split boundaries
• TypeScript/JSX transformation volume
• source map settings
• plugin count and complexity
• custom Rollup options
• dependency graph shape (deep trees, lots of CJS, etc.)
• CI CPU and filesystem I/O speed

A 40-second app might become a 12-second app. A 4-second app might become a 3-second app. A plugin-heavy app might need config fixes before it builds at all.

The biggest wins tend to show up where the current build is slow enough that developers actively avoid running it locally.

Build performance vs Core Web Vitals: the distinction that matters

This is the point worth being explicit about, because build-tool upgrade posts often blur it.

Faster builds ≠ faster pages.

Vite 8 can reduce the time it takes to produce your output assets. That is genuinely valuable — but your user's browser never sees Rolldown. It sees JavaScript files, CSS, images, and network requests.

What actually determines Core Web Vitals after a Vite upgrade:

• Did the main JS bundle get smaller or larger?
• Did chunk splitting change in a way that adds or removes request overhead?
• Did the LCP element's preload behavior change?
• Did tree-shaking improve or regress for any key dependency?
• Did long tasks on a mid-range device change?

A clean Vite 8 migration can improve build or CI time by 50% with zero effect on Lighthouse scores — and that's a good outcome. Just do not write "we upgraded Vite, therefore the site is faster for users" without measuring the actual output.

If you want to reduce bundle size as a separate concern, see the Vite React performance guide for manual chunking, lazy loading, and compression strategies that directly affect what users download. For bundle analysis in general, the Next.js bundle size guide covers approaches that apply across frameworks too.

The React plugin changes in Vite 8

@vitejs/plugin-react v6 is the version that ships with Vite 8, and it changes a few things:

• Oxc replaces Babel for React Refresh — this is faster, but it also means Babel is no longer a default dependency
• React Compiler needs explicit setup — projects that need React Compiler should use the reactCompilerPreset helper with @rolldown/plugin-babel
• @vitejs/plugin-react-swc is a separate question — Vite 8's standard plugin already uses Oxc, so the old "SWC is faster than Babel" advice needs revisiting; check current plugin guidance for your specific needs

The important point: upgrading Vite without checking the React plugin behavior is how migrations cause subtle runtime regressions. React Refresh is how HMR works in dev. Any change there deserves explicit testing.

For React performance optimization work with React Compiler: upgrade Vite first, verify the build, then add React Compiler separately. Do not combine both in one commit unless the app is very small.

What to do before upgrading

Capture a baseline before touching package.json. At minimum:

rm -rf dist
/usr/bin/time -p npm run build
find dist/assets -type f \( -name '*.js' -o -name '*.css' \) | sort
du -sh dist

Also run whatever checks your project has:

npm run typecheck
npm run test
npm run lint

Record:

• build wall-clock time
• total output size
• largest JS chunk
• largest CSS file
• number of JS and CSS files
• source map size if enabled
• a quick Lighthouse or WebPageTest run on a key page

The goal is not a lab benchmark — it is having actual numbers to compare after the upgrade so you are not guessing whether anything changed.

Upgrade path for a standard React app

For most apps, start here:

npm install vite@latest @vitejs/plugin-react@latest
npm run build
npm run preview

A minimal config still looks the same:

// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
});

If the build passes, run the production preview and walk through your real routes — not just the homepage:

• lazy-loaded routes
• dynamic imports
• SVG imports
• worker imports
• CSS modules
• auth-gated routes
• pages with charts, editors, or maps
• source maps (if enabled)

Build tools are very good at making 95% of a site work while hiding one broken edge case in the remaining 5%.

Upgrade path for large or complex apps

For apps with custom rollupOptions, custom plugins, library mode, monorepos, unusual CommonJS dependencies, or manual chunking, use a staged approach:

1. From your current Vite 7 setup, test Rolldown-specific behavior first using Vite's migration guide before doing the full major upgrade.
2. Fix any Rolldown compatibility issues.
3. Then upgrade to Vite 8.

This is worth the extra step whenever your build config is complex enough that a blind bump has meaningful risk.

Check your manual chunk config

Many React apps split vendor code with manualChunks:

// vite.config.ts
export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          react: ['react', 'react-dom'],
          charts: ['recharts'],
        },
      },
    },
  },
});

This config may still work after the upgrade, but it deserves explicit verification. Rolldown's chunking behavior is not identical to Rollup's, and chunking decisions have real user-facing effects:

• better caching and route-level splitting can reduce repeated downloads
• too many small chunks add request round-trip overhead
• large vendor chunks can block initial parse time

After upgrading, compare find dist/assets -type f | sort before and after. Look for unexpectedly large or small chunks, changes in the number of output files, and any changed preload hints in index.html.

Benchmark checklist

Run this before and after the upgrade.

Build time

rm -rf dist && /usr/bin/time -p npm run build

Run it more than once locally — machines are noisy. CI time is more reliable.

Output comparison

du -sh dist
find dist/assets -type f | sort

Check total size, largest JS file, number of JS/CSS files, and source map size.

Runtime performance

Test from a production preview, not the dev server:

npm run preview

Run Lighthouse or Chrome DevTools on key pages. Focus on:

• LCP — did the critical resource load path change?
• INP / Total Blocking Time — did long tasks change?
• CLS — any layout shift regressions?
• JavaScript transfer size — did the bundle grow or shrink?

Functional smoke test

Actually click through:

• homepage
• a lazy-loaded route
• a dashboard or data-heavy page
• a form with validation
• any auth-gated route
• any page with modals or overlays

Bundler migration bugs show up in real routes, not in Lighthouse scores.

When to wait on the upgrade

Hold off or isolate the migration if:

• you are within a few days of a major release
• your Vite config has a lot of Rollup-specific customization that you have not tested
• you are also mid-migration on React Router, React Compiler, or another core dependency
• your app uses SSR or edge runtimes (more surface area for bundler behavior to matter)
• test coverage is thin enough that you would not catch a runtime regression

A build-tool migration is supposed to reduce friction. If it arrives during a risky window, it becomes the friction.

What developers actually gain

Even if Core Web Vitals stay completely flat, a Vite 8 upgrade can be a real win:

• Local production builds become fast enough to run regularly — instead of being something developers skip
• CI feedback arrives faster — which compresses the release loop
• Bundle analysis becomes less painful — so it happens more often
• Preview deployments are quicker — making staging review more practical

This is the unglamorous side of frontend performance. The fastest user experience is built by teams whose tooling does not slow down the work of shipping it.

Recommended migration plan

1. Create a branch: upgrade/vite-8-rolldown
2. Capture build time and output sizes on the current branch
3. Upgrade: npm install vite@latest @vitejs/plugin-react@latest
4. Run typecheck, tests, lint, build, and preview
5. Compare output chunks and sizes against the baseline
6. Smoke test real routes
7. Run Lighthouse on key pages
8. Fix any config or plugin issues
9. Merge when build performance improves and runtime output is stable

For complex apps, add a step zero: test Rolldown behavior on Vite 7 first, using Vite's migration guide, before the full major upgrade.

Bottom line

Vite 8 is worth testing if production builds or CI time are already painful. The Rolldown switch is real, and the real-world build-time numbers from large apps are meaningful.

The distinction that matters:

• Rolldown can make your build faster.
• It does not automatically make your pages faster for users.

Both of those can be true simultaneously. Faster builds make it easier to do performance work — bundle analysis less annoying, previews less painful, CI feedback shorter. That indirectly benefits users, but it is not the same as shipping a smaller bundle.

Baseline first, upgrade second, measure the output. If the build drops from 40 seconds to 10 and the bundle stays clean, take the win. If the bundle changes in unexpected ways, slow down and inspect it — because build speed only matters if what you build is still what you meant to ship.