React Native Performance Q&A

Michał identifies time to interactive and dropped frames as the metrics with the strongest effect on user experience. Time to interactive usually refers to app startup, but teams can also measure how quickly a specific interaction completes. With variable refresh rates, Łukasz recommends tracking dropped frames rather than FPS.

Michał says code splitting in React Native is usually more useful for scaling needs, such as super apps or teams working independently, than for user-facing performance. Hermes already maps bytecode so it can load needed code into memory; downloading large JSON files on demand is one potential performance benefit. For faster first renders, the hosts suggest deferring or prefetching data and moving expensive calculations out of render work.

Michał says there is no single performance monitoring tool for both development and production. He names Sentry and Firebase for runtime monitoring, Flashlight and Flipper integrations for development, and Shopify's React Native Performance library for instrumentation; the hosts also mention Reassure. They describe `freezeOnBlur` as a way to pause rendering for screens that are out of focus, and advise testing for side effects.

For breaking up work, Michał points to Reanimated worklets, the native driver in Animated, and InteractionManager for scheduling work after transitions. He recommends Animated for modest animation needs, Reanimated for more extensive animation work, and Rive or Lottie when a graphics team can support them. For app size analysis, he names React Native Bundle Visualizer or Source Map Explorer for JavaScript, Android Studio's APK Analyzer for Android, and Dependencies for Apple platform apps.

Michał recommends testing with Reassure or custom Appium code and monitoring real users through tools such as Sentry or Firebase. He says migrations to the new architecture can bring unexpected issues, including text rendering problems discussed around Shopify's FlashList. He advises against spending a year solely on performance, while describing a Dream11 project where three developers spent nearly two months optimizing about ten chat UI metrics and beat the native implementation on most of them.