Big-list rendering breaks at scale because DOM size grows linearly with the dataset: 10k rows = slow initial render, hundreds of MB of memory, scroll jank, expensive re-renders.

Windowing (a.k.a. virtualization) renders only the visible slice of the list and uses a spacer to maintain correct scrollbar geometry.

The mechanism

container (height: 600px, overflow: auto)
  ↓
inner spacer (height: items.length * itemHeight, e.g. 500000px)
  ↓
visible window of ~20 rows, absolutely positioned at correct top offset

On scroll, compute which indices are visible based on scrollTop, mount those, unmount the rest. DOM size stays constant.

Libraries

Rolling your own works but is gnarly — variable heights, scroll restoration, sticky headers, a11y, RTL, window resize all need handling.

Combining with infinite scroll

Windowing handles render cost. Infinite scroll handles data cost — fetch the next page as the user nears the end:

const virtualizer = useVirtualizer({ count: items.length, ... });

useEffect(() => {
  const last = virtualizer.getVirtualItems().at(-1);
  if (last && last.index >= items.length - 10 && hasMore) {
    fetchNextPage();
  }
}, [virtualizer.getVirtualItems(), items.length, hasMore]);

Variable heights

Two strategies:

Estimated + measured: virtualizer guesses size, measures on render, updates the spacer. Slight scrollbar jitter on first scroll-through; accepted by users.

Pre-measured: if you know all heights up front, pass an array. Smooth from the start.

Sticky / pinned items

Most libraries support sticky rows (group headers). Keep the focused item pinned if it would scroll out so focus isn't lost.

Accessibility

• aria-rowcount and aria-rowindex so screen readers know total count.
• Focus management: keep the active row mounted even if scrolled out, or pin it.
• Keyboard navigation: arrow keys scroll the list, not the page.
• Ctrl-F native find only searches DOM — virtualized rows are invisible to it. Custom search UI or hidden full-text index for crawlers/find.

Performance properties

• DOM size: constant (~50 nodes regardless of dataset).
• Memory: bounded.
• Scroll FPS: 60 even on slow devices.
• Re-render: only visible rows.

Pitfalls

• Virtualizing tiny lists (< 100): overhead > benefit.
• No overscan: visible row pop-in during fast scrolls.
• Heavy children in rows: mount/unmount thrash.
• Mismatched estimateSize: jumpy scrollbar.
• Lost focus when active row unmounts.
• Forgetting Ctrl-F users will be confused.
• Animating row mount/unmount: visible flash.

When to use

Real-world examples

• Slack message list.
• Gmail inbox.
• Twitter / X timeline.
• Spotify track list.
• Notion / Airtable database views.
• Spreadsheets (2D virtualization).

Mental model

Windowing trades a bit of complexity (library + a11y considerations) for the ability to render lists of any size at constant cost. It's the standard solution for any list >1000 items in modern web apps.