Lessons From Adopting React Compiler

Hi, hope you're having a great time at React Summit 2025. Welcome to my talk where I'll be sharing my learnings from adopting the latest and greatest React Compiler in a real-world project. My name is Akash Hamilwasia. I work as an engineer at Eleven Labs, where we are building the best AI audio platform out there, including products such as Text-to-Speech, Voice Changer, Voice Cloning, Voice Design, Agents, and much, much more. You can follow me on Twitter. I go by the username at Lenderschool. I also love sharing projects on GitHub. You can check out some of my projects, again with the same username, at Lenderschool. I like sharing my learnings as technical blogs and talks at various conferences, the recordings of which you can find on my personal website akashhamilwasia.com.

In my free time, I build a video creation tool called Slantit. Slantit is a very simple and easy-to-use tool that allows you to create stunning-looking product videos from simple screen recordings really easily. You just have to drop in a screen recording, select some 3D animations and effects, and you get a nice product video that you can share on Product Hunt, on social media, or on product launch keynotes.

Now, Slantit is a very complex piece of software. It has a timeline, you can drag clips around, you can resize things, move them. It's a full-fledged video editor running on the browser. You can check it out on slantit.app. UI-heavy and creativity applications like Slantit must be extremely performant for a great user experience. React makes it easy to build complex interfaces declaratively, but performance of these complex UIs is crucial.

This is illustrated in our React Profiler Flame Graph and a screenshot from Slantit showing re-rendering issues in components. Techniques like memoization with APIs like React.memo and hooks like UseMemo and useCallback can help reduce unnecessary re-renders. By applying memoization selectively to components and logic, developers can optimize rendering efficiency and improve the user experience.

Now React makes it incredibly easy to build complex interfaces like this declaratively. But at a certain point, you cannot ignore the performance of these complex UIs. Now this is a snapshot of our React Profiler Flame Graph, something that all of us are quite familiar with. And this is a screenshot from Slantit showing which components are rendering when. I want to bring your attention to this short clip component. This component renders the individual clips that the user adds on the timeline. And in the timeline itself, the user can add let's say 20, 30, 40 different clips depending on what they are creating.

Now whenever the seek of the timeline was changing in Slantit, all the components in that particular timeline sub tree was re-rendering, which means all these short clip components, which don't even depend on the changing value on the timeline, were also re-rendering, leading to wasteful re-renders. Now React has provided us with ways to fix these unnecessary re-renders using a technique called memoization. And there are APIs like React.memo, which allow you to wrap a component and only re-render them when their props change. There's also hooks like UseMemo, which allows you to memoize certain logic inside your component and only rerun them when their dependencies change.

Some of you may not know, but you can also use UseMemo to return JSX. And this can help in memoizing certain slices of UI inside your components. So in this case, I'm memoizing the menu component and it will only re-render when name, handle, duplicate, or any of the dependencies actually change. Similar to this, there's also a use callback hook, which works as UseMemo, but it's for functions. So if we are defining any function inside your component, you can wrap it so that the component is only redefined when the dependencies actually change. Now using these APIs, you can actually reduce a lot of unnecessary re-renders, but it's very cumbersome and hard to get right. You need to figure out which component is re-rendering when, where you have to apply the memoization, and see if the props that are being passed to components should also be memoized.

For example, if you're using React.memo on a component, but you're passing functions that are being redefined in the component itself, you need to memoize them, too, with use callback hook. So it's quite hard, quite cumbersome, and honestly, you might spend a lot of years figuring out where you should apply the memoization.

To solve these issues in 2024, React team launched React Compiler in beta. React Compiler's job is to perform automatic memoization of your React code through static code analysis. It is already used at Meta in production. And just a few weeks back, on October 7th, 2025, React team launched React Compiler in beta. And just a few weeks back, on October 7th, 2025, React Compiler had its first stable release 1.0 at React Conf 2025.

The compiler's goal is to ensure only relevant parts of your app re-render when the state changes. This is also known as fine-grained reactivity, and whenever you have some state that changes, you only want the UI or the logic that depends on that state to change. You don't want the entire app to re-render or the entire component. Only the parts that are actually dependent on that state should re-render. React Compiler does this by performing static analysis of your code based on the rules of React.

Let's take a look at what these rules are. You can find a comprehensive list of all these rules on the React documentation. I'll just quickly go over them. The first group of rules cover this specific nature of components and hooks, that they are pure. So if you have side effects running in your component, make sure you run them outside of render. Props and state and arguments and return values from hooks are immutable in nature.

And the second rule says that React calls components and hooks. We are not supposed to directly call components as functions, or we shouldn't pass hook values as regular values and call them dynamically. They should be called statically at the top level. The third group is the rules of hooks itself. So if any of these rules are broken, the compiler would skip that particular component or hook.

And let's say if you have a large tree of components that are rendering, or large tree of hook calls, if there is a particular component or hook that is breaking these rules, only that particular component or hook will be skipped. The rest of the subtree will still be continued to optimize, based on whether they are actually passing the rules of React or not.

To see the compiler in action, here's a basic example. So this is a component from Slanted where I'm rendering two sliders. And when I pass this through the React compiler, this is what I get as the output. It's quite a lot of code, quite garbled, very hard to read. But if you spend some time trying to understand what it's actually doing, it's doing dependency analysis on various parts of your React code and memoizing and caching them based on what is actually changing.

In the first if branch, it checks whether the update function has changed. If that has changed, it creates a new function which calls the update function. If it hasn't changed, it just uses the value from the cache. In the second if branch, it checks whether the blur value or the callback has changed. If both have changed, it renders the settings number slider. Otherwise, it just uses the value that is there in the cache and so on.

Now, this might look like some smart AI that is doing its thing and figuring out what is actually changing, but it's just static code analysis at play. If you're thinking this is gen AI or AGI, I'm sorry, this is just code analysis that has been there since the dawn of programming languages and compiler. So to get started, make sure you're on React version 19. You can still use the compiler with React 18 and 17 via the React compiler runtime package. And the docs has instructions for using the compiler with Next.js, Vite, or even React Native project. So the compiler is not just a web thing. You can use it with any project that uses React.

There are two packages to be aware of. The first one is the Babel plugin React compiler, which is the actual React compiler that performs the transformations available as a Babel plugin. And the second package is the ESLint plugin React package, which is an ESLint plugin that surfaces any errors or analysis from the compiler based on the rules of React. My suggestion would be to start using the ESLint plugin today, even if you're not comfortable with using the compiler from the start. And remember, it's not necessary to optimize 100% of your app from the get-go.

There are instructions in the documentation where you can start by adopting the compiler in certain parts of your codebase and slowly increasing the coverage as you are more and more comfortable with how the compiler works. Once you have the compiler enabled, you will see blue badges in React DevTools next to the components. These blue badges with memo and sparkles emoji indicate that they have been auto-memoized by the React compiler. In Slanted, with the compiler enabled, the compiler was able to auto-memoize 218 out of 237 components, which is about 92% of the component coverage.

Now, do note that I already had some optimizations in place. So the time and related components, which I knew were a performance-sensitive part of the application, I already applied manual memoization in certain components over there. And I also use this concept of micro-global stores where the parts of the UI, which actually depend on certain parts of the global state, they re-render only when their dependencies change, not when the entire global state updates. Once I enabled the compiler, I instantly started seeing lesser re-renders in unoptimized parts of the app.

So things like the sidebar, which are not really performance-sensitive, they were re-rendering quite a lot, but they were not really causing any performance issues. They instantly started rendering much lesser compared to what they were before.

When I move things on the timeline, notice how the entire video player component is re-rendering all the buttons, all the sliders. When I change the slider, the toggle, the text, everything is re-rendering in that box. With the compiler enabled, when I change something on the timeline, the video player does not re-render. Only the progress slider changes because that value has changed. And even when I change the slider, the toggle, the text do not re-render. Only the slider is changing, which depends on the value that has been updated.

React Compiler is not yet a silver bullet. I encountered some issues and caveats when using the compiler in my production application. I saw a loss in reactivity in some parts of my application due to direct use of global objects outside of React. This led to components not re-rendering when expected, causing UI issues. Understanding these caveats is crucial when adopting React Compiler to avoid unexpected behavior and ensure proper UI updates.

The first caveat I encountered was I saw a loss in reactivity in some parts of my application. To understand this better, I need to show you how Slanted maintains some of its state. So timeline of Slanted is maintained as a global object. And I use getters to compute certain important values from this timeline. So here I'm computing duration based on the clips the timeline has. Similar to this, I have multiple other properties like current time progress, all of which are calculated based on the current data inside this timeline object. The timeline object itself lives outside of React and is a global state that I can access anywhere in my application.

Now, my mistake was to directly use this global object and use the duration property to render the timeline duration inside a React component. This was working when we had excessive re-renders happening where the parent component which was using VideoPlayer was re-rendering whenever the timeline was changing for some unrelated reason. And that is why the duration which was rendered by this VideoPlayer component also appeared to update. But with the excessive re-renders removed the component did not re-render when the duration changed and the compiler did not really report this because it was semantically correct. This was a global variable that is not in purview of React. It's not a React state that needs to trigger re-render. And that is why when the duration was changing the component did not re-render leading to no update on the UI. This is how it looked.

Notice when I'm adding items in the timeline inside the red circle, the duration of the timeline has not changed. When I try to move things around, certain values become infinity and nasty issues to have. And when you see them in your application, it doesn't look good. I was able to fix this issue using a package called Valtio for proxy-based reactivity. Now, Slanted is a very complex app and for some of the state updates I am using mutation-based updates. And Valtio enables proxy-based reactivity. So I'm able to directly trigger an update when certain properties of a very large state object changes. Now, with the things applied, the component now only re-renders when the duration value changes instead of when the entire timeline changes. Because the video player only depends on the duration, I only want it to re-render when the duration changes. And Valtio makes it possible because it applies these updates and triggers re-render only when the dependent values change.

So in summary, if you notice loss of reactivity in some parts of your application, remember, it's not the fault of the compiler. It's probably your fault due to some buggy code that appeared to work before the compiler was introduced. And this is typically caught using tests. But let's be honest, how many of us have actual tests to test such things? It can be solved by using React State or any state management libraries to convert any unreactive structures that you might have to reactive state that can trigger updates in your component.

The second caveat I encountered was how React Compiler treated incorrect manual memoizations. So whenever an incorrect manual memoization is encountered, the compiler simply skips optimizing such components or hooks. Here's an example of a hook that I had in Slanted. And if you take some time to notice what's wrong, the mistake over here that I have is that I'm not passing all the dependent values in the dependency area of use callback hook. Here, I'm just passing value and set value, but it's also dependent on min, max, and step. Now, this is an incorrectly memoized hook, and that is why the React Compiler would skip memoizing this particular hook itself.

To fix this, make sure you have the dependency array of useMemo and useCallback correct, and the good thing is the compiler actually tells you what's missing. This feels like a very small issue, but it's actually quite common, and it can happen a lot when you're working in teams. The best way to find such compilation issues is to use the eslint plugin to see the analysis from the compiler in the editor itself. It'll show you where you are breaking the rules of React, what you should do to fix them, and it also guides you to the right documentation to understand what the actual fix would be for that particular scenario.

To fix this, make sure you have the dependency array of useMemo and useCallback correct, and the good thing is the compiler actually tells you what's missing. So when I pass my hook inside React Compiler, it says that, hey, you have min and the max values missing, so you should probably add that. And this is honestly quite useful. This feels like a very small issue, but it's actually quite common, and it can happen a lot when you're working in teams. Where I have worked on a hook, I have written down the exact dependency array, which is used in the logic, but some other person comes in, updates the logic, but forgets to update the dependency array.

The fix for this is just to update the dependency array to have all the dependencies, or even better, just remove the manual memoization and let React Compiler do its magic. Now you might be wondering, how do I find such compilation issues? Well, the best way is to use the eslint plugin to see the analysis from the compiler in the editor itself. It'll show you where you are breaking the rules of React, what you should do to fix them, and it also guides you to the right documentation to understand what the actual fix would be for that particular scenario. You can also use the React Compiler Playground to see the analysis and issues and the output from the compiler directly on the web. So you can just bring in your code, you don't have to worry about installing dependencies or anything else, it is static analysis, so you just bring in your JavaScript code or any TypeScript code, and you can see the output, any errors or any issues. It's honestly a really great tool to actually learn how the compiler is performing and how it is working internally as well.

The third caveat I encountered was the external libraries that you use in your project will not be optimized automatically unless the library itself uses the compiler during build. Now this was a surprising finding. I thought my entire project would be optimized, including any external components that I might be using. But I noticed that a lot of my components were still re-rendering, and these components were not really written by me. They were coming from a third-party package I was using. In this case, it's coming from a package called RQI, which provides high-level components for common UI elements like accordion, menu, and so on. So these components were not memorized by the compiler and they were still re-rendering due to some unnecessary re-render. Now this is not ideal. I wish there was a better solution, but honestly the fix is that the compiler is run on the actual source code of the library and the new version is published using the compiler in the build process, and then you can install it and get the full benefit of the compiler.

If you're a library author, do install React Compiler in your build process so that all of us can benefit from the features of React Compiler in our code base as well.

The fourth caveat I would like to discuss is that sometimes the compiler's output isn't really ideal. So to explain this, here I have a very simple component. I'm rendering some conditional UI using a flag which is enabled over here. Typical JSX code, just how we do things to render UI conditionally. When you pass this through the compiler, this is the output that we get. At first, this looks correct, but there's a glaring issue over here where the first slider, which is the blur strength slider and the focal radius slider, both of them actually change when either of the blur or radius value change. Both are actually independent of each other, but because of how the JSX code is written using the conditional, React Compiler couples both the optimizations to be dependent on either of the blur or radius value change.

So if I just show how the output looks like, whenever I'm changing focal radius slider in the UI, even the blur strength slider is changing, but both are actually independent. When the focal radius changes, only that particular slider needs to be updated. So how do we go about fixing this issue? So I tried a bunch of things. I was able to actually fix this issue using an iffy. So with an iffy in the render function, I was able to use an if statement to conditionally render that particular JSX and the compiler was able to perfectly optimize this where now the blur strength slider only depends on the blur value and the focal radius slider depends only on the focal radius value.

Now, the iffy approach does not look good. I personally have never used iffys like this, or even if I have, I would extract it as a separate component and that's what I tried next. So I extracted the conditional part as a separate temporary component and it takes in all the props and then I rendered my JSX as usual and this also worked perfectly well with the compiler where now the temp component depends on both blur and radius, but inside the temp component, the settings number blur strength slider depends only on the blur and the focal radius only depends on the radius value. Now this looks great, but honestly it is a lot of work to manually extract components. I couldn't figure out how the compiler could actually do this. I think there's a flag maybe to enable this where the compiler can auto-extract such components and create these intermediate components and apply the memorizations on its own.

Now you might be wondering, how do I go about measuring the impact of the compiler after I've enabled it? You can use React Profiler or React Scan to see which components rendered and why. With React Scan, it actually makes it really easy. You just drop the React Scan script in your code base and it live highlights which components have re-rendered, how many times it has re-rendered and it also allows you to select a particular component and see why it re-rendered, which props changed, did any references change which led to that re-render. So it's super handy, much faster than React Profiler and it's really useful for seeing if the compiler is doing its job.

You can check React Scan at reactscan.com, but you can also use the good old React Profiler to actually create a Flame Graph and see if there are lesser re-renders with the compiler enabled. Here's the Flame Graph with the compiler disabled on Slanted. Notice how the Video Player component is re-rendering when a certain field changes in the app and a lot of the short clip components are also re-rendering with the entire sub-tree re-rendering inside the short clip components. With the compiler enabled, a lot of the Video Player component has been auto-memoized and only a certain slider inside Video Player changes or re-renders, because that particular value changed. The short clip components have also been memoized, but this component uses a lot of external components and those haven't been memorized, leading to some re-renders. But overall, I would say a lot of the re-renders have been minimized and only certain important components that actually need to be updated are now re-rendering.

Now, all of these look good on DevTools, on paper, but how does it actually affect our real users? So what I've noticed is that with the React compiler enabled, there's a negligible increase in bundle size. We are already shipping quite a lot of JavaScript. Just enabling the compiler did not have a massive increase in the bundle size, so it's okay to ship with the React compiler enabled. The Web Vitals like FCP and LCP were almost the same, and the reasoning for this is that all the components must render for the initial amount, and that is not when React compiler has its benefits. There might be slightly higher pass time is something that I feel because of the kind of code the compiler generates. But honestly, this is not a thing that we need to worry about. JavaScript parsing is really fast on all kinds of devices and browsers today.

The biggest change I've noticed is in the interaction to next paint core Web Vital. This core Web Vital measures how much time it takes for the next paint to happen when a user interacts with something on the page. You can measure this using performance tab or Lighthouse during development, or you can use tools like Sentry or Postdoc to measure these changes in production. So you can see whether the INP value dropped once the compiler was enabled. Now on Snagit, these are the INP values that I saw for changing a particular slider in the application. So the INP values are around 45 milliseconds to 55 milliseconds. And with the compiler enabled, these drop to around 25 milliseconds. So it was a 44% reduction in some parts of the application.

With more changes, I was able to get the compiler to optimize 222 components, which is around 94% of the components in the code base. There are still a couple of issues that I have in certain components. There is a rule in React that says do not use refs during render. I am using them in some of my components for certain optimizations. And that is why some of the components are being skipped from the compiler, which is again totally fine. Remember, you don't have to optimize 100% of the app from the get-go. You can optimize only those components that are actually causing issues and slowly increase the coverage over time. Finally, it's a great feeling to know that lesser components are actually re-rendering thanks to the React compiler. And I can go back to writing buggy code that degrades the performance, knowing that the compiler has my back to improve its performance.