FlashList vs FlatList: Recycling, Estimators, and Scroll Performance

Long-scrolling feeds are the performance bottleneck in many React Native products. FlatList virtualizes rows, but complex item layouts and unstable measurements can still cause layout thrash and JavaScript thread contention. FlashList, pioneered by Shopify, adopts a recycling model closer to native RecyclerView semantics, aggressively reusing host views and reducing allocation churn.

How recycling differs from classic virtualization

Traditional virtualization mounts and unmounts cells; recycling rebinds existing native views with new data when safe. That reduces bridge traffic and native view churn when scrolling rapidly through heterogeneous item heights—provided your renderItem path is idempotent and side-effect free.

Estimated sizes and overrideItemLayout

FlashList performs best when average item dimensions are known or tightly bounded. Supply estimatedItemSize and, where necessary, overrideItemLayout for irregular grids. Incorrect estimates cause scroll position jumps—validate against production telemetry and worst-case content (long translations, dynamic type).

When FlatList remains appropriate

Simpler lists with uniform rows, minimal native complexity, and mature getItemLayout implementations may not justify an extra dependency. Evaluate bundle size, maintenance, and library compatibility with your React Native version before migrating.

Profiling methodology

Use the in-app performance monitor, React DevTools Profiler, and platform profilers to correlate frame drops with JS long tasks. Test on low-end Android devices where garbage collection pauses dominate.

Summary

List performance is a systems problem: memoization, stable keys, image decode cost, and navigation transitions all interact. Treat benchmarks as regression tests in CI where feasible.