Performance is the feature nobody asks for and everybody notices when it is missing. After shipping over 100 React Native apps across healthcare, fintech, logistics, and consumer categories, our team has built a playbook of optimization techniques that we apply to every project. These are not theoretical best practices -- they are patterns we have validated in production with real users and real performance data.
This post covers the techniques that produce the biggest impact. We are going to work through rendering optimization, list performance, image handling, navigation, bundle size, startup time, and the Hermes engine. Each section includes the specific code patterns we use and the performance gains we typically observe.
Understanding the Performance Model
Before diving into techniques, it helps to understand what "performance" means in React Native at a mechanical level.
React Native runs two threads: the JavaScript thread and the native (UI) thread. The JS thread executes your application logic -- state management, event handling, business rules. The native thread renders the actual UI components. These threads communicate over a bridge (or, in the new architecture, through JSI -- JavaScript Interface -- which is significantly faster).
Performance problems occur when either thread cannot complete its work within the 16.67-millisecond budget required for 60 frames per second. If the JS thread is busy computing, it cannot process touch events or update state. If the native thread is busy rendering, animations stutter and the interface feels sluggish.
Most React Native performance problems are JS thread problems. The native rendering layer is fast. What slows things down is unnecessary work on the JavaScript side: re-rendering components that have not changed, computing values that could be cached, processing data that could be deferred.
Reducing Re-Renders
Unnecessary re-renders are the single most common performance problem in React Native applications. A component re-renders whenever its parent re-renders, unless you explicitly prevent it. In a deeply nested component tree, a state change at the top can trigger re-renders of hundreds of components, most of which produce identical output.
React.memo
React.memo is the first tool in the optimization toolkit. It wraps a functional component and skips re-rendering when the props have not changed.
const UserCard = React.memo(({ name, avatar, role }) => {
return (
<View style={styles.card}>
<Image source={{ uri: avatar }} style={styles.avatar} />
<Text style={styles.name}>{name}</Text>
<Text style={styles.role}>{role}</Text>
</View>
);
});
The key word is "when the props have not changed." React.memo performs a shallow comparison of props. If you pass an object or array as a prop and create a new reference on every render (even with the same values), React.memo will not help.
// This defeats React.memo because style is a new object every render
<UserCard name={name} avatar={avatar} style={{ padding: 16 }} />
// This works because style is a stable reference
const cardStyle = useMemo(() => ({ padding: 16 }), []);
<UserCard name={name} avatar={avatar} style={cardStyle} />
We apply React.memo to every component that renders inside a list and every component that is a child of a frequently-updating parent. The performance impact ranges from negligible (for components that rarely re-render anyway) to dramatic (for list items in a feed with thousands of entries).
useMemo and useCallback
useMemo caches the result of an expensive computation. useCallback caches a function reference. Both are essential for preventing unnecessary work and unnecessary re-renders.
const TransactionList = ({ transactions, filter }) => {
// Without useMemo, this filters on every render even if
// transactions and filter haven't changed
const filteredTransactions = useMemo(
() => transactions.filter(t => t.category === filter),
[transactions, filter]
);
// Without useCallback, this is a new function reference on every
// render, which causes TransactionRow to re-render even with React.memo
const handlePress = useCallback((id) => {
navigation.navigate('TransactionDetail', { id });
}, [navigation]);
return (
<FlatList
data={filteredTransactions}
renderItem={({ item }) => (
<TransactionRow transaction={item} onPress={handlePress} />
)}
keyExtractor={item => item.id}
/>
);
};
A common mistake is overusing useMemo and useCallback. If the computation is trivial (a simple property access, a string concatenation) or the function is only used in an effect, the overhead of memoization can exceed the cost of just doing the work. We apply them when profiling shows a measurable benefit or when the value is passed as a prop to a memoized child component.
State Architecture
The most impactful rendering optimization is often structural: keeping state as close to where it is consumed as possible. When you lift state to a high-level component or store it in a global state manager, every state change triggers a re-render cascade down the component tree.
// Bad: Filter state lives in the parent, causing the entire
// screen to re-render when the filter changes
const Screen = () => {
const [filter, setFilter] = useState('all');
return (
<View>
<Header />
<FilterBar value={filter} onChange={setFilter} />
<ContentList filter={filter} />
<Footer />
</View>
);
};
// Better: Extract the filter + list into a colocated component
// so Header and Footer don't re-render on filter changes
const Screen = () => {
return (
<View>
<Header />
<FilteredContent />
<Footer />
</View>
);
};
const FilteredContent = () => {
const [filter, setFilter] = useState('all');
return (
<>
<FilterBar value={filter} onChange={setFilter} />
<ContentList filter={filter} />
</>
);
};
This pattern seems trivial in isolation, but in a real application with dozens of screens and hundreds of components, the cumulative effect of proper state colocation is substantial. We have seen apps go from noticeable lag to smooth 60fps performance just by restructuring state ownership.
FlatList Optimization
FlatList is the workhorse component for rendering scrollable lists in React Native, and it is also where the most severe performance problems tend to surface. A poorly configured FlatList with a few hundred items can bring the JS thread to its knees.
The Essential Props
<FlatList
data={items}
renderItem={renderItem}
keyExtractor={keyExtractor}
// Set a fixed height for items if possible.
// This avoids layout measurement for off-screen items.
getItemLayout={(data, index) => ({
length: ITEM_HEIGHT,
offset: ITEM_HEIGHT * index,
index,
})}
// Reduce the number of items rendered beyond the visible area.
// Default is 21. For complex items, lowering this helps.
windowSize={5}
// Limit initial rendering to what's visible.
initialNumToRender={10}
// Cap the number of items rendered per batch during scrolling.
maxToRenderPerBatch={5}
// Control how often blank areas trigger new renders.
updateCellsBatchingPeriod={50}
// Remove off-screen items from the component tree.
removeClippedSubviews={true}
/>
The getItemLayout prop is the single most impactful FlatList optimization. Without it, React Native must measure every item to determine scroll position, which is expensive for large lists. With it, the framework can calculate positions mathematically. If your items have variable heights, consider using a library like @shopify/flash-list, which handles variable-height items more efficiently than FlatList.
FlashList as an Alternative
For lists with more than a few hundred items, we have largely migrated to Shopify's FlashList. It uses a recycling approach (similar to RecyclerView on Android and UICollectionView on iOS) that reuses cell components instead of creating and destroying them as items scroll in and out of view.
import { FlashList } from "@shopify/flash-list";
<FlashList
data={items}
renderItem={renderItem}
estimatedItemSize={80}
keyExtractor={item => item.id}
/>
In our benchmarks, FlashList consistently outperforms FlatList by 3-5x on JS thread frame drops for lists with 500+ items. The migration is straightforward -- the API is nearly identical to FlatList -- and we now recommend it as the default for any new project.
Memoizing renderItem
The renderItem function runs for every visible item on every re-render of the list. If it creates new closures, inline styles, or child components, you are paying that cost for every item.
// Expensive: new function and new style object for every item
const renderItem = ({ item }) => (
<Pressable onPress={() => onItemPress(item.id)} style={{ padding: 16 }}>
<Text>{item.name}</Text>
</Pressable>
);
// Optimized: stable callbacks, external styles, memoized component
const renderItem = useCallback(({ item }) => (
<MemoizedItem item={item} onPress={onItemPress} />
), [onItemPress]);
const MemoizedItem = React.memo(({ item, onPress }) => (
<Pressable onPress={() => onPress(item.id)} style={styles.item}>
<Text>{item.name}</Text>
</Pressable>
));
Image Optimization
Images are the heaviest assets in most mobile apps, and poor image handling is responsible for a disproportionate share of memory issues and perceived sluggishness.
Use Appropriately Sized Images
Never load a 2000x2000 pixel image into a 100x100 point avatar component. If your images come from a server you control, resize them server-side or use an image CDN (Cloudinary, Imgix, or similar) that generates appropriately-sized variants on the fly.
// Instead of loading the full-size image
<Image source={{ uri: `${CDN_URL}/photo.jpg` }} style={styles.avatar} />
// Request an appropriately sized variant
<Image
source={{ uri: `${CDN_URL}/photo.jpg?w=200&h=200&fit=crop` }}
style={styles.avatar}
/>
Caching Strategy
React Native's built-in Image component does not cache images aggressively on Android. For apps that display many images (social feeds, e-commerce catalogs, media galleries), we use react-native-fast-image, which provides a unified caching layer across both platforms.
import FastImage from 'react-native-fast-image';
<FastImage
source={{
uri: imageUrl,
priority: FastImage.priority.normal,
cache: FastImage.cacheControl.immutable,
}}
style={styles.image}
resizeMode={FastImage.resizeMode.cover}
/>
The cacheControl: immutable setting tells the component that this URL will always return the same image, so it can cache aggressively without revalidation. For images that change (user avatars, for example), use cacheControl: web to respect standard HTTP cache headers.
Progressive Loading
For large images that take noticeable time to load, show a low-quality placeholder immediately and fade in the full-quality image when it arrives. This is a perceived performance optimization -- the actual load time is the same, but the user experience feels significantly faster.
const ProgressiveImage = ({ uri, style }) => {
const [loaded, setLoaded] = useState(false);
return (
<View style={style}>
{!loaded && (
<View style={[StyleSheet.absoluteFill, styles.placeholder]} />
)}
<FastImage
source={{ uri }}
style={StyleSheet.absoluteFill}
onLoad={() => setLoaded(true)}
resizeMode="cover"
/>
</View>
);
};
Navigation Performance
Navigation transitions -- the animations that occur when moving between screens -- are a high-visibility performance indicator. Users notice a janky screen transition immediately, even if the rest of the app runs smoothly.
React Navigation Optimization
We use React Navigation for the majority of our projects. Out of the box, it performs well for simple navigation stacks. For complex navigation hierarchies (nested tabs, modals, drawers), specific optimizations become necessary.
Lazy screen loading. By default, React Navigation renders all screens in a tab navigator when the navigator mounts. For a tab bar with five tabs, that means five screens worth of components, effects, and data fetching executing simultaneously on first load. Enabling lazy loading defers screen rendering until the user navigates to that tab.
<Tab.Navigator
screenOptions={{
lazy: true,
// Detach inactive screens to reduce memory usage
detachInactiveScreens: true,
}}
>
<Tab.Screen name="Home" component={HomeScreen} />
<Tab.Screen name="Search" component={SearchScreen} />
<Tab.Screen name="Profile" component={ProfileScreen} />
</Tab.Navigator>
Native stack navigator. If you are still using @react-navigation/stack (the JS-based stack navigator), switch to @react-navigation/native-stack. The native stack uses platform-native navigation transitions, which run entirely on the native thread and are immune to JS thread congestion.
import { createNativeStackNavigator } from '@react-navigation/native-stack';
const Stack = createNativeStackNavigator();
This single change -- replacing the JS stack with the native stack -- typically eliminates navigation jank entirely. We have measured the difference at 40-60% fewer dropped frames during screen transitions.
Screen Component Optimization
Heavy screens that perform data fetching, complex calculations, or large renders on mount can cause visible delays during navigation transitions. The transition animation and the screen mount compete for the same JS thread resources.
The solution is to defer expensive work until after the transition completes:
import { useIsFocused } from '@react-navigation/native';
import { InteractionManager } from 'react-native';
const HeavyScreen = () => {
const [ready, setReady] = useState(false);
useEffect(() => {
const task = InteractionManager.runAfterInteractions(() => {
setReady(true);
});
return () => task.cancel();
}, []);
if (!ready) {
return <ScreenSkeleton />;
}
return <ActualScreenContent />;
};
InteractionManager.runAfterInteractions schedules work after all pending animations and interactions have completed. The screen shows a lightweight skeleton immediately (smooth transition), then renders the full content once the animation finishes.
Bundle Size Reduction
Bundle size directly affects startup time and app store download conversion rates. Users are less likely to download a 50MB app than a 15MB app, especially in markets with limited connectivity.
Analyze Before Optimizing
Before cutting anything, understand where the weight is. We use react-native-bundle-visualizer to generate a treemap of the JavaScript bundle.
npx react-native-bundle-visualizer
This visualization almost always reveals surprises. A date formatting library that contributes 200KB. A full icon set when the app uses twelve icons. A utility library imported for a single function.
Common Wins
- Replace moment.js with date-fns or dayjs. Moment.js adds 230KB (70KB gzipped) to the bundle. Day.js provides a compatible API at 2KB.
- Tree-shake icon libraries. Import individual icons instead of entire icon packs.
import { Heart } from 'lucide-react-native'instead ofimport * as Icons from 'lucide-react-native'. - Audit lodash usage. Import specific functions:
import debounce from 'lodash/debounce'instead ofimport { debounce } from 'lodash'. Better yet, replace simple lodash utilities with native JavaScript equivalents. - Remove unused dependencies. Run
npx depcheckto find packages that are installed but never imported.
In our experience, a first-pass bundle audit typically identifies 15-30% of bundle size that can be eliminated without changing any application behavior.
Hermes Engine
Hermes is Meta's JavaScript engine, purpose-built for React Native. It compiles JavaScript to bytecode at build time, which eliminates the need for on-device JIT compilation and produces dramatically faster startup times.
Hermes has been the default engine for new React Native projects since version 0.70, but we still encounter older projects running JavaScriptCore (JSC). Migrating to Hermes is one of the highest-impact single changes you can make to an existing React Native app.
The Numbers
On a mid-range Android device, switching from JSC to Hermes typically produces:
- 50-60% faster startup time. Bytecode loads faster than raw JavaScript.
- 30-40% lower memory usage. Hermes uses a more efficient memory model and includes a garbage collector optimized for mobile workloads.
- Smaller APK size. Hermes bytecode is more compact than minified JavaScript.
On iOS, the improvements are measurable but less dramatic, since JSC is already well-optimized on Apple hardware. We still recommend Hermes on iOS for consistency and because the memory usage improvements are valuable on lower-end devices.
Enabling Hermes
In react-native.config.js or your project's Gradle/Podfile configuration, Hermes is typically enabled with a single flag. For Expo projects, it is enabled by default in SDK 48 and later.
The migration is straightforward for most projects. The main compatibility concern is that Hermes does not support all ES2015+ features natively -- it covers the vast majority, but some rarely-used features like Proxy objects required polyfills in older Hermes versions. Current versions of Hermes have closed most of these gaps.
Startup Time Optimization
App startup time is the first impression. If your app takes more than two seconds to display meaningful content, users notice. If it takes more than four seconds, some users will close it and never come back.
Measuring Startup Time
We measure two metrics:
- Time to Interactive (TTI). How long from tap to the user being able to interact with the app.
- Time to First Meaningful Paint (TTFMP). How long from tap to the user seeing actual content (not a splash screen).
On iOS, you can measure TTI using Xcode Instruments. On Android, adb shell am start -W reports the total activity startup time. For cross-platform measurement, we add performance markers in the JavaScript code that log timestamps at key lifecycle points.
Optimization Techniques
Minimize root component work. Move provider initialization, store hydration, and configuration loading out of the render path. Use lazy initialization for anything that is not needed on the first screen.
// Defer non-critical initialization
const App = () => {
useEffect(() => {
// These can happen after the first render
analytics.initialize();
crashReporting.initialize();
remoteConfig.fetch();
}, []);
return <Navigation />;
};
Optimize the splash screen transition. Use react-native-splash-screen or Expo's SplashScreen API to keep the native splash screen visible until your first screen is ready to display. This prevents the user from seeing a blank white screen during JavaScript initialization.
Lazy-load secondary screens. Use React.lazy and Suspense to code-split screens that are not part of the initial navigation path.
const SettingsScreen = React.lazy(() => import('./screens/Settings'));
const ProfileScreen = React.lazy(() => import('./screens/Profile'));
Prefetch data strategically. If the home screen requires data from an API, start the fetch as early as possible -- ideally before the React tree mounts. Store the promise and consume it in the component.
Measuring What Matters
All of these optimizations are worthless without measurement. We use Flipper during development for real-time performance profiling, and we monitor production performance through crash reporting and custom performance events.
The metrics we track in production:
- App startup time (p50 and p95)
- Screen transition time by route
- JS thread frame drops per minute
- Memory usage over session duration
- Image load time (p50 and p95)
When any metric regresses, we investigate before shipping. Performance is a ratchet -- it should only go in one direction.
If you are building a React Native app and want a team that treats performance as a first-class requirement, explore our React Native development practice or browse our full services. We have been optimizing React Native apps since the framework's early days, and we bring that experience to every project.