When Rork-Built Lists Stutter: Designing Image Caching and Prefetch

Stopping decodes with expo-image

The first improvement is to swap Image for expo-image. It keeps a two-tier disk and memory cache, and passing recyclingKey suppresses both the mix-up and the re-decode when a cell is reused.

import { Image } from "expo-image";
 
function GalleryCell({ item }) {
  return (
    <Image
      source={{ uri: item.url }}
      style={{ width: 180, height: 180 }}
      recyclingKey={item.id}
      cachePolicy="memory-disk"
      transition={150}
      contentFit="cover"
    />
  );
}

The piece that matters here is recyclingKey. List cells are reused while their contents swap, so without a key the previous image can linger for a moment, or the same image gets decoded again and again. Use a stable value like item.id as the key and expo-image correctly knows that the cell's contents changed.

Set cachePolicy to memory-disk and an image read once stays in both memory and disk, so re-display never re-fetches. This change alone dropped scroll-time memory by about 40% in my setup and the hitching nearly disappeared.

Loading ahead of the visible range

Once caching stops the re-decode, the next step is to prepare the images that are about to appear. Prefetch. Starting the load the instant the user scrolls a cell into view is too late for the decode.

import { Image } from "expo-image";
 
// Preload around the visible range
function prefetchAround(items, index, radius = 6) {
  const start = Math.max(0, index - radius);
  const end = Math.min(items.length, index + radius);
  const urls = items.slice(start, end).map((i) => i.url);
  Image.prefetch(urls, "memory-disk");
}

Call this from onViewableItemsChanged and preload six items on each side as the visible range moves. The radius is a balance with device power; widen it too far and you pressure memory instead. For me, around six on each side was the right compromise between feel and consumption.

One caution: call prefetch too often and you over-fetch and over-decode. When scrolling is fast you need to thin it out — throttle how often you call it. In production, the lower the user's bandwidth, the more this design shows up in reviews.

Tuning you can do while staying on FlatList

Before adding a library, there is tuning on the FlatList side. In order of impact:

Provide getItemLayout

If cell height is fixed, pass getItemLayout. It skips layout math, so scroll start on a long list gets lighter.

Narrow windowSize

windowSize controls how many off-screen cells are kept. The default is generous, so trimming it calms memory on image lists.

Enable removeClippedSubviews

This detaches the rendering of cells that have scrolled off screen. It tends to pay off on image-centric lists, and it is where I try first.

When to move to FlashList

If it still stutters after all the tuning, consider moving from FlatList to @shopify/flash-list. FlashList recycles cells more aggressively, and memory grows more gently with large item counts.

import { FlashList } from "@shopify/flash-list";
 
<FlashList
  data={items}
  keyExtractor={(item) => item.id}
  estimatedItemSize={180}
  renderItem={({ item }) => <GalleryCell item={item} />}
/>

The one thing to watch on migration is estimatedItemSize. Pass a value far from reality and the first scroll gets shakier instead. I recommend measuring a typical cell height on device before passing it. On image lists past a few hundred items, moving to FlashList changes the feel clearly — roughly twice as smooth even on an old phone in my experience.

I will be honest about the migration cost too. FlashList moves over with nearly the same ergonomics as FlatList, but screens that lean on nested scrolling or dynamic heights can briefly break on the way. In my case the safe approach was to move a simple list like the image gallery first and leave the complex screens for later. Rather than replacing everything at once, I personally recommend migrating screen by screen, starting where the payoff is biggest.

Where to start

You do not need all of this at once. Order matters. First stop the re-decode with expo-image and recyclingKey; if that is not enough, add prefetch; and if the item count makes it fundamentally heavy, move to FlashList. Following these stages lets you tell which change earned which gain.

In your own Rork project, start by swapping the built-in Image for expo-image. In most cases the scroll feel changes from that alone. I hope this helps anyone working on the same problem.