Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Optimizing tidy: Practical Insights with the Re...

Optimizing tidy: Practical Insights with the React Compiler

Talk at the HTW x OEV Meetup Berlin

31.01.2025

Avatar for Niklas Kiefer

Niklas Kiefer

September 15, 2025
Tweet

More Decks by Niklas Kiefer

Other Decks in Programming

Transcript

  1. What to measure A click scenario from our manual integration

    testing suite • Without the compiler • With the compiler • Without manual memoization Metrics Google Lighthouse • First contentful paint (FCP) • Interaction to next paint (INP) • Total blocking time (TBT) Metrics React Profiler • Initial rendering time (IRT) More Metrics • Execution time (ET) Note: You could do the same in mobile mode
  2. Key findings: performance The react compiler doesn’t make the performance

    worse in both projects. The execution time was almost the same in all scenarios. The results vary between large design system page and application scenario. Tip: Run lighthouse in incognito mode *with compiler compared to without compiler
  3. Key findings: performance In the agent-frontend click scenario, all performance

    metrics are slightly better or the same with the compiler and with manual memoization. *with compiler compared to without compiler First Contentful Paint +-0% Total Blocking Time +-0% Initial Rendering Time -6,9% Interaction to next paint +-0%
  4. Key findings: performance In the agent-frontend click scenario, leaving out

    manual memoization and trusting the compiler makes it faster - except initial rendering time *without manual memoization compared to with First Contentful Paint +-0% Total Blocking Time -37,5% Initial Rendering Time +5% Interaction to next paint -31,25%
  5. Key findings: performance In the design system page, all performance

    metrics are best with the compiler and with manual memoization. *with compiler compared to without compiler First Contentful Paint -3,4% Total Blocking Time -33,3% Initial Rendering Time -0,66% Interaction to next paint +-0%
  6. Key findings: performance In the design system page, leaving out

    manual memoization and trusting the compiler makes it slower. *without manual memoization compared to with First Contentful Paint +1,16% Total Blocking Time +27,78% Initial Rendering Time +3,54% Interaction to next paint +6,67%
  7. Key findings: dev experience • It works with both React

    18 and 19 • Configuration as easy as three lines of code • Less memos, less cognitive load • “Pull requests [without memoization] took 31-46% longer to author”* *Source: https://react.dev/blog/2024/10/21/react-compiler-beta-release#react-compiler-at-meta
  8. Key findings: dev experience However: Eslint errors make it hard

    to simply run it • Components got skipped because some rules were disabled • Blindly following the React ESLint rules breaks the application • Needs component refactoring to proper integrate compiler
  9. Key findings: dev experience However: Refactoring out all manual memoization

    is a pain (GPT helps) • Starting in a new application would be easier to handle for sure • But: Leaving out memoization creates an abstraction layer
  10. Conclusion • The React Compiler can save you some unnecessary

    re-rendering + improve the performance of your application • At least it does not make things worse
  11. Conclusion • The React Compiler can save you some unnecessary

    re-rendering + improve the performance of your application • At least it does not make things worse However: • More components => less reliability • It’s not production ready (working group) • It won’t catch all unnecessary re-rendering • You can’t simply forget everything you know about useMemo, useCallback & … • Good architecture over trusting a black-box compiler
  12. Further reading • React Compiler Playground • How React Compiler

    Performs on Real Code • React Compiler Docs • Discussions · GitHub - reactwg react-compiler • React Compiler Stableness Update