perf: Enable React Compiler for improved runtime performance 🚀

[sanjaiyan-dev]

Description:
This PR integrates the React Compiler to align the framework with modern React standards and improve overall performance.

Key Benefits:

• Performance: According to Meta’s benchmarks, this can improve initial loads by up to 12% and make interactions up to 2.5× faster.
• Standardization: Follows the latest recommendations for compiling libraries.
• Stability: The compiler is now stable (v1) and has been adopted by major frameworks like Next.js.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit d789930:

Sandbox	Source
example	Configuration

[travisbreaks]

A few concerns before this ships:

1. No R3F-specific benchmarks. The cited Meta numbers are from standard React DOM apps. R3F's hot path is useFrame running at 60fps with imperative ref mutations, which is architecturally different from anything Meta benchmarked. Can you share before/after measurements on a non-trivial R3F scene (e.g., the drei storybook or an examples page)?

2. Compiler + imperative mutation compatibility. R3F's core patterns rely heavily on mutating Three.js objects via refs inside useFrame, and the reconciler itself does imperative property application outside standard React render flow. The compiler's auto-memoization assumes pure rendering and standard React semantics. Without explicit "use no memo" directives on critical paths (the reconciler, useFrame internals, useThree), there's a real risk of silent miscompilation where closures get incorrectly cached or JSX elements get over-memoized.

3. No compiler configuration. This applies babel-plugin-react-compiler with zero config to the entire library. At minimum, I'd expect to see compilationMode and targeted opt-outs for the reconciler and frame loop internals. Shipping this as the default for all R3F users without an escape hatch is a significant surface area change for a minor bump.

[CodyJasonBennett]

react-three-fiber isn't a component library that can take advantage of compiler memoization—we ship the React runtime it implements over. So, the common advice for libraries is moot here. I would accept improvements to documentation or examples to leverage the compiler, or a similar change to component libraries over react-three-fiber, such as Drei.

[sanjaiyan-dev]

A few concerns before this ships:

1. No R3F-specific benchmarks. The cited Meta numbers are from standard React DOM apps. R3F's hot path is useFrame running at 60fps with imperative ref mutations, which is architecturally different from anything Meta benchmarked. Can you share before/after measurements on a non-trivial R3F scene (e.g., the drei storybook or an examples page)?
2. Compiler + imperative mutation compatibility. R3F's core patterns rely heavily on mutating Three.js objects via refs inside useFrame, and the reconciler itself does imperative property application outside standard React render flow. The compiler's auto-memoization assumes pure rendering and standard React semantics. Without explicit "use no memo" directives on critical paths (the reconciler, useFrame internals, useThree), there's a real risk of silent miscompilation where closures get incorrectly cached or JSX elements get over-memoized.
3. No compiler configuration. This applies babel-plugin-react-compiler with zero config to the entire library. At minimum, I'd expect to see compilationMode and targeted opt-outs for the reconciler and frame loop internals. Shipping this as the default for all R3F users without an escape hatch is a significant surface area change for a minor bump.

Hi,

Thank you for your feedback and suggestions! Sorry for the delay in my response.

To address your points:

1. Benchmarking: I agree that this is necessary to verify the impact. I will work on creating a benchmark to validate the performance improvements.
2. Implementation Strategy: Using the annotation-based mode is a great suggestion. I will adjust the configuration to opt-in via annotations, which should help us maintain stability and control during the transition.

[sanjaiyan-dev]

react-three-fiber isn't a component library that can take advantage of compiler memoization—we ship the React runtime it implements over. So, the common advice for libraries is moot here. I would accept improvements to documentation or examples to leverage the compiler, or a similar change to component libraries over react-three-fiber, such as Drei.

Ah, got it! I'll open a PR in react-three/drei instead. Apologies for the confusion—I originally thought it would be helpful to add these optimizations directly to core hooks like useLoader and useGraph.