React Compiler eliminates useMemo and useCallback in React 19. Here's how to enable it in Next.js App Router, its limits, and pitfalls to avoid in 2026.
The React Compiler automatically memoizes your components and values without you writing a single useMemo or useCallback. In practice: the compiler analyzes your code at build time and injects memoization itself where it makes sense, which should drastically reduce the number of unnecessary re-renders in a React 19 app.
But does it actually work in a Next.js App Router app in production, today? We dug into it, tested it on a real project, and here's what we found: activation, limitations, and cases where you should leave it alone.
What the react compiler actually does
The React Compiler is a tool that runs at build time and transforms your source code to automatically inject memoization. No new API to learn, no additional hooks. It reads your components as you write them today—with props, states, dependencies—and figures out for itself where a manual useMemo or useCallback would have been necessary.
Before the compiler, a developer had to guess which expensive calculations deserved memoization, and manually list dependencies for each hook. Guess is the right word. We've all forgotten a dependency in a useCallback array and debugged stale state for two hours.
The compiler removes this human responsibility. It applies a simple rule: if a component follows React's rules (no direct prop mutation, no side effects during render), it can be analyzed statically and memoized automatically.
What actually changes for your team: code becomes shorter, more readable, and most importantly, harder to break by accident. Something that often surprises teams making the migration: removing all existing useMemo manually sometimes improves performance because the compiler does more careful work than what a rushed human would have written.
What the compiler doesn't do
It doesn't replace business logic. It also doesn't guess your business intentions—if your component has a logic bug, the compiler will never fix it. It optimizes rendering, period.
How to enable it in a next.js app router app
Activation happens at the build level, via a dedicated Babel plugin configured in your project. On an existing Next.js App Router project, the typical approach looks like this:
- Install the React Compiler plugin as a dev dependency.
- Enable it in your Next.js configuration (
next.config.js), usually via an experimental option while the feature continues to mature. - Run a full build and compare the bundle before and after—the compiler adds memoization code, so bundle size can slightly increase.
- Test thoroughly the components with complex state: multi-step forms, filterable lists, anything that depends on precise re-renders.
- Progressively remove existing manual
useMemo/useCallback—not all at once.
Point 5 is what everyone misses. You want to clean up the code all at once after activation. Bad idea. The compiler coexists just fine with already-memoized code, so nothing forces you to rewrite everything on activation day.
The pitfalls we encountered testing the compiler
Here, we need to be honest: it doesn't go smoothly everywhere.
First pitfall: components that quietly violate React's rules—direct mutation of an object passed as props, side effects hidden in conditional rendering—simply aren't optimized by the compiler. Worse, they can produce inconsistent behavior between dev and compiled mode, making debugging harder than before.
Second pitfall: third-party libraries. If your app depends on external components that don't follow these rules, the compiler simply leaves them alone. So you don't get uniform gains across the whole app, but gains concentrated on your own code.
Third pitfall, more subtle: on a project where developers had already done rigorous manual memoization, the measured performance gain was small. The compiler shines most where the team didn't have time or discipline to memoize properly—which is the case for most projects, let's be honest.
This approach has a clear limit: it doesn't work well if your codebase contains many legacy class components, or code that manipulates the DOM directly outside the React render cycle. In that case, migrating to standard functional components before enabling the compiler remains a mandatory prerequisite.
Comparison table: manual memoization vs react compiler
| Criterion | Manual memoization (useMemo/useCallback) | React Compiler |
|---|---|---|
| Developer effort | High—each case must be identified and coded | Low—automatic at build time |
| Error risk | Forgotten dependencies, stale state bugs | Reduced, but depends on following React rules |
| Code readability | Cluttered with hooks everywhere | Source code closer to natural rendering |
| Coverage | Targeted where dev thought to add it | Uniform across every conforming component |
| Third-party library compatibility | Not relevant | Doesn't apply to non-conforming external components |
| Maturity in 2026 | Standard for years | Available but still marked experimental on some configs |
Conclusion
Three things to remember before enabling the React Compiler on your next Next.js project. First, it doesn't replace rigor: code that violates React's rules is code the compiler can't save. Second, real gains depend on your current codebase state—the shoddier your manual memoization was, the more visible the gain will be. Finally, migration must be progressive: enable, test, then clean up existing code, never the other way around.
If your team is already working on a larger Next.js migration, we actually covered this in our article on Next.js 15 end-of-life and the migration plan to version 16—the compiler is part of the projects to integrate into that roadmap rather than treat as a separate initiative. And if the topic of build and compilers in general interests you, we also dug into what the native TypeScript compiler in Go changes for your build times.
Need an audit before migrating your app to the React Compiler? Contact fstck.co so we can look together at whether your codebase is ready.
Frequently asked questions
Does the react compiler work with react class components?
No. The compiler only analyzes functional components and hooks. A codebase with many legacy class components must first be migrated to functional components before it can benefit from the compiler.
Should i remove all existing usememo and usecallback after enabling the compiler?
No, and it's even discouraged to do it all at once. The compiler coexists without issues with already-memoized code. Better to enable, measure, then progressively clean up component by component.
Does the react compiler slow down build time on a large next.js project?
Yes, static analysis adds build cost, usually moderate on medium-sized projects. On very large monorepos, this cost deserves to be measured before production, by comparing build times before and after on your CI.
Can you use the react compiler with next.js pages router, or only app router?
The compiler acts at the Babel build level, independent of which router you use. It therefore works in theory with Pages Router too, but most experience reports and documentation in 2026 focus on App Router projects.
How do i know if my code follows react's rules needed for the compiler?
A dedicated ESLint plugin can detect violations before you even enable the compiler at build time. This is the recommended first step: run the linter on your entire codebase, fix reported violations, then only then enable the compiler.
