React Native List Performance — ScrollView, FlatList, SectionList, FlashList

Your feed scrolls fine with 20 items.

Ship 2,000 and the UI starts hitching, memory climbs, and “just wrap it in a ScrollView” becomes the bug report.

Lists are where most React Native apps feel slow. Not because RN is slow — because the wrong list API (or the right one, misconfigured) forces the JS thread and the UI thread to do work they shouldn’t.

This is the practical guide: which component to pick, how recycling actually works, and the knobs that matter in production.

---

TL;DR

Component	Best for	Virtualizes?	Recycles views?	Scale
ScrollView	Short, fixed content	❌ mounts all	❌	~tens of items
FlatList	Long homogeneous lists	✅	✅ (limited)	hundreds–low thousands
SectionList	Grouped lists (A–Z, dates)	✅	✅ (limited)	hundreds–low thousands
FlashList (@shopify/flash-list)	Long lists that must feel native	✅	✅ (aggressive)	thousands+

Rule of thumb

1. If every child mounts at once → not a list for large data. Use virtualization.
2. Prefer FlashList for feeds, catalogs, chats, search results.
3. Use FlatList / SectionList when you want zero extra deps or need sticky section headers with RN primitives.
4. Use ScrollView only when the content is small and known.

---

Mental model: what makes a list “slow”

A scrollable screen can be slow for three different reasons. Optimize the right one.

1) Mount cost
   Too many React trees created up front
   → blank screen, high JS heap, slow first paint

2) Frame cost (scroll jank)
   Too much work per frame while scrolling
   → dropped frames, sticky fingers

3) Memory cost
   Too many native views / images retained
   → OOM, background kills, iOS jetsam

Virtualization attacks (1) and (3).

Recycling + lighter rows attack (2).

Image strategy and memoization finish the job.

ScrollView
  [ item ][ item ][ item ] ... [ item ]   ← all mounted

FlatList / SectionList / FlashList
  viewport + overscan window
  ┌─────────────────────────┐
  │  recycled row cells     │  ← only these exist in native UI
  └─────────────────────────┘
         ↕ bind new data as you scroll

---

1. ScrollView — when it’s correct (and when it’s a footgun)

ScrollView renders every child immediately. No windowing. No recycling.

Use it when

• Settings screens, forms, onboarding steps
• Content height is roughly one or two screens
• You need nested layout that isn’t a data-driven list
• Item count is small and stable (say under 20–30 simple rows)

Don’t use it when

• data.map(...) over API results of unknown length
• Chat history, product grids, notification feeds
• Anything that grows with user data

Anti-pattern

// ❌ Looks fine in demos. Dies in production.
<ScrollView>
  {products.map(item => (
    <ProductCard key={item.id} item={item} />
  ))}
</ScrollView>

Why it hurts:

• All ProductCard components mount on open
• All images may start loading
• Native view hierarchy is huge
• Scroll is smooth until it isn’t — then memory and JS GC thrash

Nested ScrollView + list = pain

Avoid:

<ScrollView>
  <Header />
  <FlatList data={items} ... />  {/* nested VirtualizedList warning / broken windowing */}
</ScrollView>

Prefer:

• One list with ListHeaderComponent / ListFooterComponent
• Or FlashList’s similar header/footer APIs
• Or a single scroll surface (don’t nest vertical scrollers)

⚠️ Warning: Nesting a vertical FlatList inside a vertical ScrollView breaks windowing. You’ll often get the “VirtualizedLists should never be nested…” warning — and real jank.

---

2. FlatList — the default virtualized list

FlatList is a convenience wrapper over VirtualizedList. It only mounts items near the viewport (plus a render window), and reuses some native cells as you scroll.

Minimal solid setup

import { FlatList, Pressable, Text } from 'react-native';
import { memo, useCallback } from 'react';

const Row = memo(function Row({ item, onPress }) {
  return (
    <Pressable onPress={() => onPress(item.id)} style={styles.row}>
      <Text>{item.title}</Text>
    </Pressable>
  );
});

function ProductList({ products, onOpen }) {
  const renderItem = useCallback(
    ({ item }) => <Row item={item} onPress={onOpen} />,
    [onOpen],
  );

  const keyExtractor = useCallback(item => item.id, []);

  return (
    <FlatList
      data={products}
      renderItem={renderItem}
      keyExtractor={keyExtractor}
      initialNumToRender={10}
      maxToRenderPerBatch={10}
      windowSize={5}
      removeClippedSubviews
    />
  );
}

Props that actually matter

Prop	What it does	Guidance
keyExtractor	Stable identity for recycling	Use a real id, never index alone for mutable lists
getItemLayout	Skip measuring if rows are fixed height	Big win when every row is the same height
initialNumToRender	First paint batch	Keep close to what’s on screen (~8–12)
maxToRenderPerBatch	How many items per JS batch while scrolling	Lower = less JS spike, higher = fewer blanks
windowSize	Viewport multiples kept mounted	Default 21 is heavy; try 5–10
updateCellsBatchingPeriod	Delay between batches (ms)	Raise slightly if scroll feels choppy from JS
removeClippedSubviews	Detach offscreen native views	Often helps Android; verify no missing views
ListEmptyComponent	Empty state	Avoid conditional whole-list unmount flicker

Fixed-height turbo: getItemLayout

If every row is 72 px tall:

const ITEM_HEIGHT = 72;

const getItemLayout = useCallback(
  (_data, index) => ({
    length: ITEM_HEIGHT,
    offset: ITEM_HEIGHT * index,
    index,
  }),
  [],
);

<FlatList getItemLayout={getItemLayout} /* ... */ />

You skip async layout measurement. Jump-to-index and scroll restoration get cheaper and more accurate.

Variable-height rows? Skip this, or maintain your own offset cache carefully.

The extraData trap

FlatList does a shallow compare on data. Selection state living outside data won’t re-render rows unless you tell it:

<FlatList
  data={items}
  extraData={selectedId} // force rows to update when selection changes
  renderItem={({ item }) => (
    <Row item={item} selected={item.id === selectedId} />
  )}
/>

Inline functions and anonymous rows

These recreate every parent render and defeat memo:

// ❌ new function + new component type every render
<FlatList
  renderItem={({ item }) => <Row item={item} onPress={() => go(item.id)} />}
/>

Prefer stable renderItem, memoized row, and stable handlers (pass id, handle in row, or use a context/ref for callbacks).

Images in FlatList rows

• Size images explicitly (width / height)
• Use a caching library (react-native-fast-image or Expo Image)
• Don’t decode huge assets into tiny thumbnails without resizing
• Use recycling-aware placeholders so recycled cells don’t flash the wrong image (cancel / version tokens)

---

3. SectionList — grouped data without fighting FlatList

SectionList is FlatList’s cousin for sectioned data:

[
  { title: 'A', data: [/* contacts */] },
  { title: 'B', data: [/* ... */] },
]

Solid pattern

import { SectionList, Text, View } from 'react-native';
import { memo, useCallback } from 'react';

const ContactRow = memo(function ContactRow({ item }) {
  return (
    <View style={styles.row}>
      <Text>{item.name}</Text>
    </View>
  );
});

function ContactsScreen({ sections }) {
  const renderItem = useCallback(
    ({ item }) => <ContactRow item={item} />,
    [],
  );

  const renderSectionHeader = useCallback(
    ({ section: { title } }) => (
      <View style={styles.header}>
        <Text style={styles.headerText}>{title}</Text>
      </View>
    ),
    [],
  );

  return (
    <SectionList
      sections={sections}
      keyExtractor={item => item.id}
      renderItem={renderItem}
      renderSectionHeader={renderSectionHeader}
      stickySectionHeadersEnabled
      initialNumToRender={12}
      windowSize={7}
      removeClippedSubviews
    />
  );
}

SectionList gotchas

1. Same optimization rules as FlatList — memo rows, stable keys, tune window props.
2. Sticky headers have platform quirks — test Android carefully.
3. Don’t rebuild sections every render with a fresh array/object graph if data didn’t change — that invalidates list reconciliation.
4. Mixed item types (header-like rows inside data) make recycling harder — keep headers as real section headers.
5. For very large sectioned datasets (e.g. 10k contacts), consider FlashList + manual sticky headers or a specialized contacts UI.

When SectionList is the wrong tool

• Fake sections by stuffing headers into a flat array and branching in renderItem — works, but you lose sticky header semantics and complicate getItemLayout
• Nested SectionLists
• Tiny static grouped content — a ScrollView with plain Views is simpler

---

4. FlashList — when FlatList’s recycling isn’t enough

@shopify/flash-list is built for blank-free, high-FPS lists. It recycles views more aggressively and asks you to help with item type and size estimates.

Install

yarn add @shopify/flash-list

# iOS
cd ios && pod install

Baseline migration from FlatList

import { FlashList } from '@shopify/flash-list';
import { memo, useCallback } from 'react';
import { Text, View } from 'react-native';

const Row = memo(function Row({ item }) {
  return (
    <View style={styles.row}>
      <Text>{item.title}</Text>
    </View>
  );
});

function Feed({ items }) {
  const renderItem = useCallback(({ item }) => <Row item={item} />, []);

  return (
    <FlashList
      data={items}
      renderItem={renderItem}
      keyExtractor={item => item.id}
      estimatedItemSize={72} // critical in v1; confirm for your version
    />
  );
}

💡 Version note: FlashList API evolved (v1 → v2). Always confirm current required props (estimatedItemSize vs newer sizing APIs) for the version you install. The ideas stay the same: estimate sizes, separate item types, keep rows pure.

Why FlashList feels faster

FlatList	FlashList
Conservative recycling	Cell recycling tuned like native RecyclerView / UICollectionView
More blank cells under fast fling	Fewer blanks when configured well
Measurement churn on variable heights	Size estimates + recycling reduce thrash
Easy defaults, easier to misuse	Slightly more setup, better ceiling

Item types — don’t skip this

If row layouts differ (text-only vs image vs ad), tell FlashList so it recycles like-with-like:

<FlashList
  data={items}
  renderItem={renderItem}
  estimatedItemSize={80}
  getItemType={item => item.kind} // 'text' | 'media' | 'ad'
/>

Without this, a tall media cell may be reused for a short text row → layout jumps / wasted work.

Headers, footers, empty states

<FlashList
  data={items}
  ListHeaderComponent={Header}
  ListFooterComponent={isLoading ? FooterSpinner : null}
  ListEmptyComponent={Empty}
  renderItem={renderItem}
  estimatedItemSize={72}
/>

Grid with FlashList

<FlashList
  data={products}
  numColumns={2}
  renderItem={renderItem}
  estimatedItemSize={220}
/>

Keep column cell heights predictable. Wildly different cell heights in a grid are where you earn your performance scars.

FlashList as a SectionList alternative

FlashList doesn’t replace SectionList 1:1. Common approach:

1. Flatten sections into one array with { type: 'header' | 'row', ... }
2. getItemType returns 'header' vs 'row'
3. Implement sticky headers via FlashList sticky props / a custom overlay if you need them

More work than SectionList, but worth it at large scale.

---

Optimization checklist (all virtualized lists)

Copy/paste PR checklist

Data & identity

• [ ] Stable keyExtractor / keys from server ids
• [ ] Avoid using array index as key when items reorder/insert
• [ ] Don’t clone data / sections every render
• [ ] Paginate on the server (limit / cursor) — UI virtualization ≠ fetching the world

Row components

• [ ] memo row components
• [ ] Cheap rows: no heavy hooks work per row on every parent render
• [ ] Avoid anonymous renderItem that closes over changing values unnecessarily
• [ ] Move press handlers carefully (stable callback or row-local)
• [ ] Don’t put the entire screen state into every row via props

Layout

• [ ] Prefer fixed heights + getItemLayout (FlatList / SectionList)
• [ ] Provide accurate size estimates (FlashList)
• [ ] Separate heterogeneous layouts with item types (FlashList)
• [ ] No nested VirtualizedLists in the same orientation
• [ ] Use ListHeaderComponent instead of ScrollView wrapping a list

JS thread hygiene

• [ ] Keep renderItem pure and fast
• [ ] Debounce filtering/sorting; do heavy work off the critical path
• [ ] Prefer InteractionManager.runAfterInteractions for non-urgent work after push
• [ ] Profile with React DevTools + RN Perf monitor before “optimizing” randomly

Images & media

• [ ] Explicit dimensions
• [ ] Cache and prioritize visible URLs
• [ ] Blurhash / LQIP placeholders beat layout jumps
• [ ] Recycle-safe binding (don’t show previous item’s avatar)

Tuning knobs (FlatList / SectionList)

Start conservative, measure, then adjust:

initialNumToRender={8}
maxToRenderPerBatch={8}
windowSize={5}
updateCellsBatchingPeriod={50}
removeClippedSubviews

• See blank areas while flinging → increase windowSize / batch size
• See JS thread spikes → decrease them and lighten rows

---

Choosing the right tool — decision flow

Is the content short and fixed?
  YES → ScrollView (or plain View)
  NO  ↓

Do you need sticky section headers with minimal setup?
  YES → SectionList (or FlashList + sticky strategy if huge)
  NO  ↓

Is the list long / fling-heavy / heterogeneous / business-critical FPS?
  YES → FlashList
  NO  → FlatList is fine

Practical defaults for common screens

Screen	Recommendation
Settings	ScrollView
Inbox / notifications	FlashList (or tuned FlatList)
Chat messages	FlashList inverted / maintain visible content
Product catalog grid	FlashList + numColumns
Contacts A–Z	SectionList until scale hurts, then flatten + FlashList
Horizontal carousels	FlatList / FlashList horizontal; don’t nest badly with parent vertical list
Search results	Virtualized list + pagination + cancel in-flight requests

---

Nested lists without shooting yourself

Horizontal list inside vertical list is common (Netflix-style rows).

function ShelfRow({ shelf }) {
  return (
    <View>
      <Text>{shelf.title}</Text>
      <FlatList
        horizontal
        data={shelf.items}
        keyExtractor={item => item.id}
        renderItem={renderShelfItem}
        showsHorizontalScrollIndicator={false}
        initialNumToRender={4}
        windowSize={3}
      />
    </View>
  );
}

function Home({ shelves }) {
  return (
    <FlashList
      data={shelves}
      keyExtractor={s => s.id}
      renderItem={({ item }) => <ShelfRow shelf={item} />}
      estimatedItemSize={220}
    />
  );
}

Rules:

• Different orientations → OK
• Same orientation nested virtualization → almost always wrong
• Memoize ShelfRow
• Don’t give every horizontal list a huge windowSize

---

Profiling: prove the win

Guessing is how you ship React.memo theater.

1. Enable perf monitor in the dev menu — watch JS / UI FPS while flinging
2. Why did you render? / React DevTools — catch rows re-rendering for no reason
3. FlashList recycling warnings — fix estimated sizes / item types
4. Xcode Instruments / Android Studio Profiler — native memory & overdraw
5. Compare:
   • time to first contentful list paint
   • FPS during fast fling
   • memory after scrolling to end and back

A real win looks like: same features, higher floor FPS, lower memory, fewer blank cells.

---

Production patterns that pay rent

Pagination + list

const onEndReached = useCallback(() => {
  if (hasMore && !loadingMore) {
    fetchNextPage();
  }
}, [hasMore, loadingMore, fetchNextPage]);

<FlashList
  data={items}
  onEndReached={onEndReached}
  onEndReachedThreshold={0.5}
  ListFooterComponent={loadingMore ? <Spinner /> : null}
  estimatedItemSize={72}
  renderItem={renderItem}
/>

💡 Tip: Guard onEndReached — it can fire more than you think.

Optimistic updates & sparse changes

• Update by id with a stable array strategy (e.g. React Query / normalized store)
• Avoid re-creating every row object if nothing changed
• For selection, store selectedId once; derive UI in the row; use extraData on FlatList

Avoid layout thrash in rows

// ❌ measuring & setting state in every row on mount
useEffect(() => {
  rowRef.current?.measureInWindow(/* ... */);
}, []);

Measure once at list level, or use fixed layout. Per-row measurement is how “beautiful” lists become jank machines.

Don’t animate everything

Enter animations on every recycled row re-bind look cool once and expensive forever. Animate mounts sparingly; prefer list-level transitions.

---

Quick “stop doing this” list

1. ScrollView + .map for feeds
2. Index keys on dynamic data
3. Anonymous renderItem + inline arrow props breaking memo
4. Nested vertical FlatList inside ScrollView
5. Fetching 10,000 rows “because FlatList virtualizes” (network + JS memory still pay)
6. Heavy Context values changing every keystroke while a list is mounted
7. Ignoring estimatedItemSize / item types in FlashList
8. Complex chart/video in every offscreen row with a huge window

---

Cheat sheet

ScrollView     → small, static, non-virtualized content
FlatList       → default virtualized list, tune window props
SectionList    → virtualized + sticky sections, same tuning mindset
FlashList      → best FPS / recycling for real feeds at scale

Always
  - stable keys
  - memoized rows
  - light renderItem
  - pagination
  - no nested same-orientation VirtualizedLists

Measure
  - blank cells → increase window / fix sizes / use FlashList
  - JS stutters → shrink batches, lighten rows, memoize
  - memory → smaller window, recycle images, fewer heavy subtrees

---

Closing

Virtualization is not a silver bullet — it’s a contract.

You promise: stable identity, predictable row layout, cheap renders.

The list promises: only a window of items exists at a time.

Break the contract with ScrollView for unbounded data, unstable keys, or bloated rows, and no windowSize tweak will save you.

Start with the simplest component that fits the screen. When the list becomes a product surface people fling through all day — graduate to FlashList, measure FPS, and keep rows boring.

Boring rows scroll fast.

---

Further reading

• React Native — Using List Views
• FlatList docs
• SectionList docs
• Shopify FlashList
• React Native Performance