The Large List Rendering Problem

Suppose you map over an array of ten thousand items and render a li for each. React will dutifully create ten thousand DOM nodes, even though only a couple dozen fit on screen at once.

Most of those nodes are off-screen and invisible, yet the browser must still create, lay out, and maintain every one of them.

The browser pays a real cost for large DOM trees. Layout, style recalculation, and memory all scale with node count, so a huge list slows initial render and inflates memory usage.

Even simple interactions can stutter when the engine has tens of thousands of nodes to track and reflow.

Scrolling a massive list is where users feel the pain most. The browser repaints and may recompute layout as content moves, and with too many nodes the frame rate drops below smooth.

The result is janky, laggy scrolling that makes the interface feel unresponsive no matter how fast the rest of the app is.

You can confirm the problem in the browser DevTools Memory panel, which reports the number of DOM nodes on the page. A list that creates thousands of nodes shows up clearly here.

Watching that count balloon as you render more items gives you concrete evidence that the DOM size is the bottleneck.

Virtualization, sometimes called windowing, renders only the items currently visible plus a small buffer, rather than the entire list. As you scroll, items entering view are mounted and those leaving are unmounted.

This keeps the live DOM tiny regardless of how many items the data contains, decoupling DOM size from dataset size.

The visible window is derived from the scroll position, the container height, and the item height. Dividing the viewport height by item height gives roughly how many rows fit, and scroll offset tells which rows those are.

The library uses these numbers to decide exactly which slice of items to render at any moment.

Several libraries implement windowing. react-virtualized is feature-rich but larger, react-window is a smaller, focused rewrite by the same author, and TanStack Virtual is a modern headless option.

For most lists, react-window offers an excellent balance of simplicity and performance, which is why this course focuses on it.

Virtualization pays off when lists are long, roughly several hundred rows or more, or when rows are heavy with images and nested components. Those are the cases where DOM size genuinely hurts.

Infinite feeds, large data tables, and chat histories are typical scenarios where windowing becomes essential rather than optional.

For short lists of a few dozen simple items, virtualization adds complexity without meaningful benefit. The absolute positioning and measurement overhead can even be a net negative.

Reserve windowing for genuinely large datasets; for small ones, a plain map is simpler and perfectly fast.

With windowing, a list of a hundred thousand items keeps only the visible handful in the DOM, so initial render is fast, memory stays low, and scrolling is smooth.

You trade a little complexity in setup for performance that no longer depends on how much data you have, which is the core promise of virtualization.

Decide when virtualization is worthwhile.

Rendering thousands of DOM nodes inflates layout cost, memory, and scroll jank, which you can confirm via the DevTools node count. Virtualization renders only the visible window plus a buffer, keeping the DOM small.

react-window is a focused, lightweight choice among react-virtualized and TanStack Virtual. Use it for large or heavy lists, and skip it for short, simple ones.