Virtualizing Long Lists

The plain-language idea

Rendering a long list the naive way — one real DOM node per item, all at once — costs more than it looks like it should, and the cost isn't concentrated in one place. More nodes means more work for Layout to position, more work for Paint to fill in pixels for, and more memory held for elements that are, at any given moment, mostly not even visible. A viewport can only physically show a small window of rows; everything else is rendered and paid for without ever being seen.

List virtualization (also called "windowing") fixes this by rendering only the items currently within the visible scroll viewport, plus a small buffer of extra rows just outside it. As the user scrolls, the same small set of real DOM nodes gets reused — their content swapped to represent whichever data items have scrolled into range — instead of creating and destroying thousands of nodes. The DOM node count stays roughly constant no matter how large the underlying list actually is; only which data each node currently displays changes.

See it in a real thing: 10,000 rows, a dozen or so rendered

// Naive: creates one real DOM node per item, all 10,000 at once
function NaiveList({ items }) {
  return (
    <div style={{ overflowY: "auto", height: 500 }}>
      {items.map((item) => (
        <Row key={item.id} item={item} />
      ))}
    </div>
  );
}

// Virtualized: only rows in (or near) the visible window are real DOM nodes
function VirtualList({ items, rowHeight = 40, viewportHeight = 500 }) {
  const [scrollTop, setScrollTop] = useState(0);
  const startIndex = Math.floor(scrollTop / rowHeight);
  const visibleCount = Math.ceil(viewportHeight / rowHeight) + 4; // small buffer
  const visibleItems = items.slice(startIndex, startIndex + visibleCount);

  return (
    <div style={{ overflowY: "auto", height: viewportHeight }} onScroll={(e) => setScrollTop(e.currentTarget.scrollTop)}>
      {/* A spacer the full height of ALL items — this is what makes the scrollbar behave correctly */}
      <div style={{ height: items.length * rowHeight, position: "relative" }}>
        {visibleItems.map((item, i) => (
          <div key={item.id} style={{ position: "absolute", top: (startIndex + i) * rowHeight, height: rowHeight }}>
            <Row item={item} />
          </div>
        ))}
      </div>
    </div>
  );
}

A long list of 40 items, scrolled near the top — only a handful are within the visible viewport.

BackNext

The full-height spacer div is what makes this work visually: it gives the scroll container the correct total scrollable height (so the scrollbar's size and position look exactly like all 10,000 rows exist), while the actual rendered rows are absolutely positioned inside it based on their real index, and there are only ever a couple dozen of them in the DOM at once. Scroll the container, scrollTop changes, startIndex recalculates, and a different slice of items gets rendered into the same small set of DOM nodes.

What people usually miss

Watch out

• Variable-height items are meaningfully harder than fixed-height ones. Fixed row height makes startIndex a simple division. Variable height requires measuring rendered items and maintaining a position cache — most virtualization libraries support it, but it's a real complexity jump, not a minor detail.
• Browser find-in-page (Ctrl/Cmd+F) and some accessibility tooling expect content to exist in the DOM to find it. A virtualized list's off-screen items genuinely aren't in the DOM, so searching for text in a row that isn't currently rendered won't find it — a real, known tradeoff, not a bug to "just fix."
• It's the wrong tool for short lists. A list of 20-30 items doesn't have a rendering-cost problem worth solving, and the added complexity (spacer math, absolute positioning, scroll listeners) isn't worth paying for a list that small — virtualization earns its cost at genuinely large counts (thousands of rows), not as a default.
• The spacer element, not the visible rows, is what keeps scrollbar behavior correct. Forgetting it (or sizing it wrong) is the most common virtualization bug — the scrollbar thumb size and scroll range depend entirely on that full-height placeholder.

Why this matters in interviews

"How would you render a list of 100,000 rows without freezing the page?" is a common systems-flavored frontend question, and explaining the windowing mechanism — a fixed small set of real DOM nodes with swapped content, backed by a full-height spacer for correct scroll behavior — demonstrates real understanding, versus just naming a library.