React Native Performance in 2026: The Checklist That Matters

Most React Native performance advice is a list of tricks: memoise this, avoid that, use this library. Some of it matters a lot; much of it doesn't matter for your app at all. The difference is measurement. Optimising without measuring is how teams spend a week shaving milliseconds off a screen nobody opens while the main feed stutters.

This is the React Native performance optimization checklist I'd run on any app in 2026, ordered by where the wins usually are, with how to check each item. It's written for current React Native with the New Architecture and Hermes, which every app on a supported version now uses.

Key takeaways

• Measure first, on a mid-range Android phone, in a release build. Debug builds are dramatically slower and misleading.
• The biggest wins are usually startup work, list rendering, images and unnecessary re-renders.
• Use the modern tools: FlashList or LegendList for long lists, expo-image for images, Reanimated for animations, and the React Compiler to automate memoisation.
• Keep heavy work off the JavaScript thread during interactions and animations on the UI thread.
• Monitor in production, because real devices and real data reveal problems no test phone will.

Step 1: measure

Write down baseline numbers (cold start, a key list's scroll smoothness, a key screen's time to interactive) before changing anything, and re-measure after each change.

You can also mark your own moments. The Web Performance APIs became stable in React Native 0.83, so performance.mark() and performance.measure() work as they do on the web, show up in the DevTools Performance panel, and can be read at runtime with PerformanceObserver:

performance.mark("feed-start");
const items = await loadFeed();
performance.mark("feed-ready");
performance.measure("feed-load", "feed-start", "feed-ready");

The checklist

Startup

• Hermes enabled (it's the default; Hermes V1 since React Native 0.84).
• No heavy work at module scope; SDKs initialised after the first frame where possible.
• Splash screen held only for essentials; fonts, auth and config loaded in parallel.
• First screen rendered from cached data, refreshed in the background.

Re-renders

• The React Compiler enabled where possible, or careful use of React.memo, useMemo and useCallback on hot paths.
• State kept as local as possible; global stores subscribed with selectors, not whole objects.
• No new objects or inline functions passed to memoised list rows on every render.
• Context split so frequently changing values don't re-render the whole tree.

Lists

• Long lists use FlashList (v2 requires the New Architecture and needs no size estimates) or LegendList, not ScrollView with map.
• List rows are light: no heavy computation, images sized correctly, minimal nesting.
• Stable keyExtractor values; no index keys for dynamic data.
• Pagination or infinite loading instead of rendering thousands of items.

Images

• expo-image (or another caching component) with memory and disk caching.
• Images served at display size, in modern formats.
• Placeholders for stable layout; prefetching for the next screen where useful.

Animations and gestures

• Reanimated (or the native driver) so animations run on the UI thread.
• Gesture Handler for gestures, connected to Reanimated shared values.
• No state updates on every frame of an animation.

Navigation

• Native stack navigation (Expo Router's default stack or @react-navigation/native-stack) rather than JavaScript-driven transitions.
• Tab screens mounted lazily, so the app doesn't render every tab at launch.
• Heavy work on screen focus deferred until after the transition finishes.

JavaScript thread

• Heavy work (parsing big files, encryption, image processing) moved off the interaction path, deferred or done natively.
• No synchronous storage reads of large data during navigation.
• Network responses paginated and trimmed to what the screen needs.

Memory

• Listeners, intervals and subscriptions cleaned up when screens unmount.
• Large images not held in memory unnecessarily.
• Long-running screens (feeds, chats) checked for growth over time in a profiler.

Bundle and app size

• Unused dependencies removed; heavy libraries replaced with lighter ones.
• Android App Bundles with code shrinking for release builds.

From the field: On React Native apps I've worked on, I cut load time by about 60% (3.8 seconds to 1.5) through Hermes, image optimisation and cache-first fetching while holding stable 60fps animation, and scaled one app to 100K+ active users at 99.9% crash-free sessions. That's why I'd start any performance work with a measurement, not a guess.

Common React Native performance issues and fixes

React Native performance vs native (Kotlin and Swift)

React Native draws real platform views, so a well-built screen scrolls and animates like a native one. Where fully native code still wins is sustained heavy computation (image or audio processing, cryptography, large data transforms) and features that call platform APIs many times per second. The answer isn't to rewrite the app. Move that specific work into native code: a Turbo Module or Expo module in Swift and Kotlin, or C++ shared by both platforms through JSI. Libraries such as react-native-quick-crypto take this approach, implementing cryptography in C++ instead of JavaScript.

Newer frameworks join these comparisons too. Lynx, which ByteDance open-sourced in March 2025, runs UI work on its own thread by design, but its ecosystem is still young and published comparisons are early. For production apps today, profiling your own React Native screens beats any framework benchmark.

Monitoring performance in production

Your test phones aren't your users' phones. Track a few metrics from real devices, per release:

• Cold start time, broken down by app version and device class.
• Slow and frozen frames on key screens such as feeds, chat and checkout.
• Screen load time for the screens that matter to revenue.
• ANR rate on Android, which Google Play also measures.

Tools such as Sentry's performance monitoring, EAS Observe and Firebase Performance Monitoring report these, and a release that makes them worse should be treated like a release that adds crashes.

The React Compiler

React's compiler, stable since late 2025, automatically memoises components and values at build time, which removes much of the manual useMemo and useCallback work and the bugs that come with it. It works with React Native, and Expo lets you enable it in app config. It doesn't replace good architecture (it can't fix a list that renders 5,000 rows), but it removes a common source of unnecessary re-renders.

Common performance myths

FAQ

How do I improve React Native performance?

Measure first on a real mid-range device with a release build, then fix the biggest problems: startup work, list rendering (FlashList or LegendList), image sizes and caching, unnecessary re-renders (the React Compiler or targeted memoisation) and animations off the JavaScript thread (Reanimated). Re-measure after each change.

Why is my React Native app slow on Android but fine on iOS?

Many Android test devices are much slower than recent iPhones, so heavy JavaScript, large images and long lists show up there first. Profile on a mid-range Android phone in a release build, and optimise lists, images and startup work.

Is FlashList faster than FlatList?

For long or complex lists, usually yes. FlashList recycles views instead of creating new ones as you scroll, and version 2, built for the New Architecture, handles item sizing automatically. For short, simple lists, FlatList is fine.

Does the React Compiler work with React Native?

Yes. The React Compiler automatically memoises components and values at build time, and it can be enabled in React Native projects, including through Expo's app config. It reduces unnecessary re-renders but doesn't replace good list and data architecture.

Next steps

If your app feels slow and you're not sure why, I can profile it on real devices and give you a prioritised list of fixes, starting with the ones users will notice most. Get in touch, or see how I work as a React Native developer.

Sources

• Performance overview, React Native docs
• React Native DevTools, React Native docs
• FlashList v2 migration guide, Shopify
• React Compiler, React
• Image (expo-image), Expo
• React Native 0.83: new DevTools features, React Native blog