Virtualization (also called windowing) is the technique of rendering only the visible window of items in a long list, regardless of how many items the dataset contains.

Why

A list of 10,000 DOM nodes:

• Initial render: layout + paint for all 10k → seconds.
• Memory: tens to hundreds of MB.
• Scroll: every frame touches the whole DOM.
• Re-render: all items recompute.

Virtualized:

• DOM has ~20–50 nodes at any time.
• Memory: small + bounded.
• Scroll: only the few visible mount/unmount.
• Re-render: only visible items.

The model

The container is the viewport (fixed height, scrollable). Inside, a single inner element has the total height (items.length × itemHeight) — that makes the scrollbar match a "full" list. Inside that spacer, only the currently-visible window of items is rendered, absolutely positioned at the correct top offset.

container (height: 600px, overflow: auto)
└─ inner (height: 10000 * 50 = 500000px)
   └─ row 200 at top: 10000px
   └─ row 201 at top: 10050px
   └─ ... (visible window only)
   └─ row 211 at top: 10550px

On scroll, compute which rows are in view, mount those, unmount the rest.

Example with TanStack Virtual

import { useVirtualizer } from '@tanstack/react-virtual';

function VirtualList({ items }) {
  const parentRef = useRef(null);
  const v = useVirtualizer({
    count: items.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 50,
    overscan: 5,            // render 5 extra rows above/below for smooth scroll
  });

  return (
    <div ref={parentRef} style={{ height: 600, overflow: 'auto' }}>
      <div style={{ height: v.getTotalSize(), position: 'relative' }}>
        {v.getVirtualItems().map(row => (
          <div
            key={row.key}
            data-index={row.index}
            ref={v.measureElement}    // for dynamic heights
            style={{
              position: 'absolute',
              top: 0,
              left: 0,
              width: '100%',
              transform: `translateY(${row.start}px)`,
            }}
          >
            <Row item={items[row.index]} />
          </div>
        ))}
      </div>
    </div>
  );
}

Libraries

Hard parts

Variable item heights: easiest if known upfront. Dynamic measurement (Virtuoso, TanStack) measures rows as they render and updates the spacer — the scrollbar can shift slightly during the first scroll pass.

Scroll restoration: when navigating away and back, the focused row may not be in the DOM. Persist the scroll offset (sessionStorage) and re-apply after data hydrates.

Sticky headers / group sections: most libraries support sticky rows; you mark a row as sticky and the library keeps it pinned during scroll.

Accessibility:

• aria-rowcount on the container so screen readers know the total.
• Focus management: if the focused row scrolls out, decide between unmounting (focus lost) or pinning (DOM kept).
• Keyboard navigation: arrow keys should scroll the list, not the page.

Find-in-page (Ctrl-F): browser's native find only searches DOM. Virtualized rows aren't findable. Workarounds: custom search UI, or render the searchable text in an off-screen visually-hidden element.

Animations: row mount/unmount can flash. Use overscan to mount before scrolling reveals the row.

Grid (2D) virtualization: harder. TanStack Virtual and react-window both support it; column virtualization is independent of row.

When to virtualize

Pitfalls

• Mounting heavy children inside each row — every scroll mounts/unmounts → expensive. Memoize and keep row components light.
• Forgetting overscan — rows pop in visibly during fast scrolls.
• Mismatched estimateSize vs actual — scrollbar jumps.
• Lost focus when the focused row unmounts.
• Trying to use Ctrl-F in production and finding only visible rows.
• Stacking virtualization inside virtualization (rare but possible) — gets weird.

When not

• Small lists.
• Lists where every row needs SEO indexing (Google crawler won't run scroll JS).
• Lists where Ctrl-F is critical (settings list, command palette).

Mental model

Virtualization keeps DOM size constant. Pay a small complexity cost (library, a11y considerations, scroll restoration) to make 100k-row lists smooth. It's the standard solution for "scale" lists in modern apps.