Adopting the compiler in Sanity Studio

[stipsan]

At Sanity we've been testing the compiler on Sanity Studio, to help improve the end user experience for people that are creating content, editing content, simply working with all sorts of content.
As the Studio is a real-time application (no save button here!), multiplayer and collaborative (constant state reconciliation of your local mutations and the remote "source of truth"), with potentially large documents, deeply nested fields, granular revision history, complex custom validation rules, sophisticated ACL that's also real-time. Let's just say that there are a lot of stuff going on that can interrupt you typing into a field and then cause jank.

When the React Compiler was announced, and given that its main focus is rerender performance, it made sense for us to join the WG and test out its potential.
While we've been testing the compiler internally ever since, we haven't been able to test it in production on our npm libraries, and Sanity Studio is distributed on npm, since we have to maintain compatibility with React 18.
With the beta launch adding official support for React 18 that changed, and we have so far this week shipped these libraries that are optimised by the compiler, and thus depend on the react-compiler-runtime dependency:

• react-rx – which lives on the hottest paths on our state management in the Sanity Studio, as well as many other apps in our production.
• @sanity/ui – our design system, used by all our apps, and the Studio, one of our most performance sensitive libraries and the most hand-optimised of them all.
• @portabletext/editor – our rich text editor, extremely hand-optimised, and performance sensitive as it has to grapple with Google-Docs-style problems.

The rollout has been pretty painless, and we have so far not encountered an issue where we had to turn off the compiler or add 'use no memo' directives. Only react-rx has zero warnings from eslint-plugin-react-compiler, while @sanity/ui and @portabletext/editor have some warnings. What that has meant in practice to us is that there are opportunities where we can refactor code so that the compiler can optimise it, and reap further performance improvements.
The only issues we've encountered that we've forwarded to the core team has been cases where the compiler thinks we're violating a rule of react, that has turned out to be a valid pattern that the compiler needs to support.

For example for a while the compiler refused to optimise this pattern:

const Component = React.forwardRef((props, forwardedRef) => {
  const ref = useRef()

  useImperativeHandle(forwardedRef, () => ref.current) // <- linter would throw "Ref values (the `current` property) may not be accessed during render."

  useEffect(() => {
    ref.current?.focus();
  }, [])

  return <input ref={ref} />
})

The compiler have since added full support for this pattern ❤

In practice this means that the compiler has either skipped over a component it could've optimised safely, or it'll uncover a bug in our code that we should fix any way.
In fact, some of the bugs it has helped us uncover have been pretty wild.
It's not just that the eslint-plugin-react-compiler itself works really well as a bug detection tool, I'm talking about how babel-plugin-react-compiler has helped solve "cold case" bugs by forcing them to the surface.

While enabling the compiler on @portabletext/editor we saw a couple of tests failing in its gherkin testing suite, that runs e2e tests with playwright.
@christianhg dove in to verify what was going on and uncovered that the failing tests had actually been false positives all along. For a long time we've seen that our editor sometimes failed to toggle bold/italics at the edge of decorators, and we couldn't find a way to reliably reproduce this case. Enabling the compiler on our vitest testing suite forced this edge case to the surface and made it consistently happen and lead to us resolving the case 🥳

The next step for us is to enable the compiler on the Sanity Studio codebase itself, we're currently testing it, and our eFPS suite is reporting really good numbers:

Our eFPS suite measures the FPS during editing interactions, like typing into a title field, rich text fields, different scenarios where any latency really impacts the user experience and can prevent a creative professional from being able to stay in a good and productive feedback loop.
A 20-30% increase in how many frames that can render per second is really significant! I want to put it into context:

• The test suite ran with the new versions of @portabletext/editor, @sanity/ui and @portabletext/editor.
• In the suite we added babel-plugin-react-compiler and simply turned it on for the sanity codebase, which drives Sanity Studio.
• Again, we simply turned the compiler on, that's just a few hours and days of total effort, and we're seeing a 20% faster product, that's wild.

Some more context, in @sanity/ui and @portabletext/editor the compiler is skipping components on some really hot paths. Some of the components will need to be refactored, as they are genuinely breaking the rules of react. Others will need to wait for the compiler to support use cases that are on its todo-list, for example code that uses try/catch.
In other words we see massive untapped potential that we'll be able to reap as we incrementally refactor the codebase and report issues to the core team so that the compiler can learn to handle valid cases that it's currently skipping over and not optimising.

For the Sanity Studio itself this is especially true as the linter currently reports 80(!) issues, which happens to be most of the hottest paths in our codebase. A lot of them are already hand optimised, but we know that there are cases where a couple of unstable dependencies are able to poke holes through these manual optimisations that the react compiler is doing a good job at solving. We expect a significant impact once we're able to have the compiler handle those.

All in all, don't sleep on the compiler! Incrementally adopt it like we have:

1. Add the eslint-plugin-react-compiler and use it to detect bugs that need to be fixed.
2. Add the babel-plugin-react-compiler to staged envs to measure its impact and verify it doesn't cause regressions.
3. Start using the react-compiler-runtime to ship optimised code for react 18.
4. Continue shipping code and incrementally refactor code that the compiler is skipping, to increase the performance benefits and lower memory usage the compiler results in.

[ThomasCarca]

Hello, very interesting insights, thank you so much for sharing !
I am new to the concept of what you call an "eFPS suite", do you mind elaborating a bit on that ?
I find it particularly important to have clear metrics on how the performance of the app changes based on a feature being rolled out.
Is it some kind of performance analysis tool you have developed within the Sanity Studio ?

[ricokahler]

Is it some kind of performance analysis tool you have developed within the Sanity Studio ?

yup, "eFPS" (editor frames per second) is an internal Studio metric that frames input latency as a frame rate, primarily to make it intuitive to interpret (like how 30fps is good, 60fps is great):

efps = 1000ms / input latency

How we measure it:

1. Use Playwright to simulate keypress events
2. Set up a MutationObserver to track DOM value changes + timestamps
3. Record timestamps at keypress (Playwright) and value update (browser)
4. Calculate input latency per keypress
5. Take the median latency and convert to eFPS

Some important context about our editor:

• Has significant synchronous operations that impact performance (eFPS measures more than react perf)
• It currently re-renders the entire editor on any value change with no granular subscriptions atm (big reason we ❤️ react compiler!)
• Measurement precision limited to milliseconds (Playwright → browser timestamps)
• Metric captures both React performance and editor logic overhead

Given these constraints, seeing a 20-30% performance improvement just by enabling the compiler (with no code changes from us) is particularly impressive!

[ThomasCarca]

Thank you for this clarification, this makes a lot of sense. 🙏

[bhojpress]

I think React 19.1.0 removed forwardRef and it now directly supports the ref. React compiler is moving forward with 19+ concepts and thus you should only adopt compiler in the similar way. Try using direct ref and see if it accepts to optimize. 🚀

[stipsan]

forwardRef isn't removed yet, it's marked as deprecated.
Breaking changes are first announced, then deprecated, and finally removed in a next major.
The compiler supports and optimizes forwardRef just fine:

And there's no change in compiler output if props.ref is used instead:

It is true that the React Compiler have more opportunities to speed things up if the baseline is React 19 and newer features are used, for example React.use(Context) allows conditionally subscribing to a context, and the compiler supports it. This pattern can have significant impact on your perf. The opportunity to remove React.forwardRef and just use props.ref is more about simplicity than it is perf.