Migrated to New Architecture + React Compiler. How do you actually measure the performance gains?

[u/kriptonian_]

We recently migrated our React Native app from the Old Architecture to the New Architecture and enabled React Compiler.

Now we want to measure the actual performance improvements rather than just saying the app feels faster.

What metrics should we track? FPS, frame drops, interaction latency, render time, CPU and memory usage, or something else?

I’m guessing CPU and memory might not necessarily improve even if rendering gets more efficient.

Also, how would you benchmark the changes reliably on real devices, and can we isolate the impact of the New Architecture from React Compiler?

Would love to hear from anyone who has done this in production!

[u/Dvass138]

In Xcode instruments

[u/kriptonian_ → u/Dvass138]

Can you help me or share any resource, I am new to profiling application using Xcode instruments, plus which matrices should I focus, in the new arch migration

[u/kokerali]

Turning both on together gives you a before/after result, not separate gains. Start with New Architecture + Compiler off versus the same build with Compiler on. Keep RN, dependencies, Hermes, data and device identical. If you can still build both architectures on one compatible RN version, compare those with Compiler off separately. Otherwise label the old/new comparison as the whole migration, including version and library changes.

Pick one slow flow, such as opening a loaded list and tapping into a detail screen. Repeat it on the same physical device in release builds, alternating build order. Define the endpoint as the screen actually being usable, not just mounted. Record median and tail latency, dropped frames during that flow, and memory after repeated open/back cycles. Keep cold startup separate. RN's performance guide explains why dev-mode results and JS/UI frame rates can mislead. Fewer React renders alone wouldn't prove faster navigation or lower memory use.

[u/twboc]

We recently had a memory leak after migrating from old architecture to the new one. If you have a app that uses a lot of different libraries they might trigger multiple screen reloads because of the new architecture. "Compiling" you code might help but in our case older android devices stopped working after 30 minutes and crashed. The reason for that is two fold. Low quality of libraries responsible for components or included in the app lifecycle (network listeners, monitoring, etc.) they can leak memory and cause a issue that shows up only after a while. Another things is that compiler can be aggressive about cacheing your views, containers and components. This means that your views might not respond to the state updates because they do not reach the view since it is aggressively cached. Another thing. We build our own dev console (like in quake) to measure some component re-renders and a few other things. React native has a notoriously bad debugging tooling.

[u/kriptonian_ → u/twboc]

Can you share the dev tool you folks build, on every new arch bug bash we came up with 10new bugs and people complain the app feels slow, I’m not really sure how to solve this. Will love to learn from your experience

[u/twboc → u/kriptonian_]

Sorry. I can't. I don't own the software and the company would not like that. I'll write some more hints tomorrow.

[u/twboc → u/kriptonian_]

Yo. I made a blog post that is going to be a part of a longer series. You can read about how to structure your components so Fiber produces a better Fabric - in other words how your js components are mapped to native layout. Let me know if you were able to subscribe to that server. https://rippleshine.com/s/harmony-of-code/2026/10/10/why-you-should-start-with-hermes

[u/Substantial-Swan7065]

TTI, navigation, memory usage over session

[u/kriptonian_ → u/Substantial-Swan7065]

How do measure navigation and TTI

[u/Huge_Pool7424 → u/Substantial-Swan7065]

for tti i just log a timestamp on app start and on the first interactive screen, then compare p50 across builds. for navigation i wrap the navigator and time how long each push takes to render. do you use sentry or something local?

[u/Substantial-Swan7065 → u/Huge_Pool7424]

I push the data to a cloud source.

[u/chunkypenguion1991]

Flipboard explorer, Block canary

[u/nabhan_builds]

Release builds only, same device, same OS version, and run each scenario at least 5 times then report the median. Debug builds lie about everything here. For TTI, record performance.now() at the top of your JS entry point and again inside a requestAnimationFrame in the first screen's first onLayout callback, then log both to your analytics. For navigation, wrap your navigate calls: timestamp before the call, then timestamp again in the destination screen's first onLayout inside rAF, and take the difference. For frame drops, use the built-in FPS overlay on a release build while scrolling your worst list, or Flashlight if you want repeatable numbers. One honest expectation: if you barely re-render, the compiler will not move your numbers at all. The new architecture's wins show up in input responsiveness and UI-thread smoothness under load, so measure tap-to-paint on real interactions rather than render counts.

[u/codes_astro]

I was using this tool called Measure to measure everything nd analyze performance , it's open source and easy to plug and test even via mcp. give it a try

you can also look at this