You enabled React Compiler in a Vite project, but nothing obvious changed. The first thing to check is not whether the app feels faster: it is whether the installed Vite React plugin supports the configuration you used, whether the compiler actually ran, and whether the component was eligible for optimization. React Compiler reduces some unnecessary re-renders and repeated calculations; it does not guarantee a visible speedup on every page.
Start with the installed versions and the setup path
Check the versions resolved by your lockfile, not only the version range in package.json:
npm ls react react-dom @vitejs/plugin-react babel-plugin-react-compiler @rolldown/plugin-babel oxc-transform-reactThe package version matters because Vite’s React plugin changed its Babel integration. In @vitejs/plugin-react 6, the old inline react({ babel: { plugins: [...] } }) option was removed. The React documentation’s Vite setup for this plugin version uses @rolldown/plugin-babel and the exported reactCompilerPreset. Copying a pre-v6 example into v6 can therefore leave you with a configuration that does not enable the compiler as intended.
Recommended Vite route: React’s Babel preset integration
For the documented Vite path, install the compiler and the Babel integration:
npm install -D babel-plugin-react-compiler @rolldown/plugin-babelThen configure the plugins as shown in the official React installation guide:
import { defineConfig } from 'vite'
import react, { reactCompilerPreset } from '@vitejs/plugin-react'
import babel from '@rolldown/plugin-babel'
export default defineConfig({
plugins: [
react(),
babel({ presets: [reactCompilerPreset()] }),
],
})Do not also add the old inline Babel option to react() when using plugin-react v6. Keep one intentional compiler integration, then restart the dev server and make a production build. If your project has additional Babel transforms, verify their ordering and configuration against the tool’s documentation.
There is also an experimental native Vite/OXC route
The Vite React plugin changelog introduced experimental native React Compiler support in version 6.1.0, using oxc-transform-react and react({ compiler: true }). This is a separate path from the documented Babel preset setup. The React documentation still describes the compiler primarily as a Babel plugin and says first-class OXC support is being developed. If you choose the native route, treat it as experimental, check the current plugin changelog and compatibility notes, and avoid enabling both integrations at once.
// Experimental native path; verify compatibility for your installed versions
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
export default defineConfig({
plugins: [react({ compiler: true })],
})A setting copied from the experimental OXC example should not be mixed with Babel configuration just because both mention “React Compiler.” Choose the route that matches your project and the current official documentation.
Prove compilation happened
A successful build alone is not proof that every component was optimized. React Compiler can safely skip code it cannot compile. Use more than one check:
- Open React DevTools in development and check whether eligible components show the compiler’s Memo badge.
- Inspect transformed build output for compiler-generated memoization, following the official verification guide.
- Check the build log and diagnostics options for your installed plugin version. In the Vite plugin changelog, diagnostics became opt-in in version 6.1.1, so an empty console is not by itself evidence that compilation did or did not run.
- Profile a representative interaction before and after with the same data and environment. Compare render counts or interaction duration, and keep the optimization only if the measured result matters.
The compiler primarily targets update performance: avoiding cascading component re-renders and repeating expensive render-time calculations. It does not automatically speed up network requests, large non-React computations shared across many components, slow server responses, or every initial page load. Profile first so you are measuring the problem the compiler can address.
If it compiles but the app behaves differently
Separate a build error from a runtime behavior issue. React’s troubleshooting guide says the compiler is designed to skip many patterns that could be unsafe, but runtime issues can still surface when code violates the Rules of React in ways the compiler cannot detect. A common trap is relying on memoization for correctness—for example, assuming an object reference will always remain stable so an effect runs only once.
To isolate one component, React documents the temporary "use no memo" directive. If disabling compilation for that component removes the regression, investigate the component’s state, purity, hook usage, and effect dependencies. Fix the underlying issue, test it, and remove the directive when the component is safe to compile. Do not use the directive as a permanent substitute for debugging.
Quick diagnosis
| What you see | What to check next |
|---|---|
| Old example has no effect after upgrading plugin-react | Check whether the project is on v6; use the current reactCompilerPreset integration or intentionally choose the experimental OXC path. |
| Build succeeds but no component badge appears | Confirm the compiler is configured, inspect eligible components and build output, and check diagnostics settings. |
| Only some components appear optimized | That can be expected; check React Rules diagnostics and whether the component is eligible. |
| Behavior regresses after enabling compilation | Isolate the affected component with "use no memo", inspect Rules of React violations, then test a targeted fix. |
| No measurable speed change | Profile the interaction. The compiler does not remove network, server, or unrelated computation bottlenecks. |
Frequently asked questions
Does React Compiler make every Vite page faster?
No. It can reduce certain re-renders and repeated render-time calculations. Measure the affected interaction; a page dominated by network or server time may not change.
Can I leave useMemo and useCallback in existing code?
Yes. React’s guidance is to leave existing manual memoization in place or test carefully before removing it. Do not do a broad cleanup as part of turning on the compiler.
Why do I see no compiler warning?
Some plugin versions do not print recoverable diagnostics by default. Check the changelog for your resolved version and use the documented diagnostics option when available. Verify with DevTools or transformed output too.
Should I use the experimental native compiler option?
Only if you deliberately accept an experimental integration and have checked its compatibility for your installed Vite, plugin, and compiler versions. For the standard setup, follow React’s installation documentation.
Sources and scope
- React Compiler installation guide — Vite setup, plugin-react v6 Babel integration, verification steps, and supported React versions.
- React Compiler introduction — what is optimized and what the compiler does not memoize.
- React Compiler debugging guide — compiler skips, runtime issues, the Rules of React, and temporary opt-out.
- Vite React plugin changelog — v6 Babel removal, experimental native compiler support in 6.1.0, and diagnostics behavior in 6.1.1.
- @vitejs/plugin-react package page — package metadata and current release information; verify your local lockfile because versions move.
Checked against official documentation and the project changelog on 2026-10-13. No Vite project was built or benchmarked for this article; commands are troubleshooting guidance, not claimed test results. Exact compatibility depends on your installed versions and project configuration.