Rendering cost and virtualization: the 10,000-row table that renders 30 rows

Why 10,000 rows is slow twice

A big list hurts you in two separate engines, and memoization only talks to one of them. First, the React cost: an update that touches the list — a filter keystroke, a sort, a websocket tick — re-renders row components. Even a cheap 0.1 ms row times 10,000 is a full second of render phase, and React.memo only helps for rows whose props did not change, which a filter by definition defeats. Second, the browser cost, which exists even when React is idle: a row of eight cells is easily 30+ DOM nodes, so 10k rows is ~300k nodes that consume memory, slow down style recalculation, and make every layout pass touch a document tens of thousands of pixels tall. This is why the Hook team’s memoization shaved 0.2 s and no more — they optimized the React engine while the layout engine was the one drowning.

The structural observation that fixes both: the viewport shows maybe 25 rows. Everything else is rendered, laid out, and painted for nobody. Virtualization (windowing) renders only the visible slice into a container with one tall spacer element preserving the scrollbar geometry, and repositions the slice as the user scrolls. React renders 30 components instead of 10,000; the browser owns 1,500 nodes instead of 300,000. The list becomes O(viewport) instead of O(data).

TanStack Virtual: the mechanics

When you reach for a virtualizer, the first question is: does it force a specific DOM structure on you, or does it stay out of your markup? TanStack Virtual is headless — it owns the math, you own the HTML — which matters the moment you need a custom row layout or a non-standard scroll container.

A headless virtualizer like TanStack Virtual does three jobs: track scroll position, decide which indexes are visible, and tell you where to absolutely position them. You keep full ownership of the markup:

function TransactionList({ items }) {
  const parentRef = useRef(null);
  const virtualizer = useVirtualizer({
    count: items.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 44,   // px guess per row — corrected by measurement
    overscan: 5,              // extra rows above/below the viewport
  });

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

The moving parts are worth naming. estimateSize is a guess; for dynamic heights, measureElement observes each mounted row and replaces the guess with reality, shifting the offsets of everything below — a wildly wrong estimate makes the scrollbar jump as measurements come in, so estimate from your real median row. overscan renders a few extra rows beyond the viewport so fast scrolling shows content instead of blank flashes; each unit of overscan is rendering you paid for that may never be seen, so 3–10 is the usual range, not 50. Failure modes to expect: position: sticky headers do not work naturally inside a transform-positioned list (the virtualizer’s own translate breaks the sticky containing block — pin headers outside the scroll container, or use the virtualizer’s sticky-item support); and remote data needs the count from the server before the scrollbar can be honest.

content-visibility: the CSS alternative

Sometimes you cannot virtualize — the markup comes from a CMS, the list is semantic content where find-in-page and Ctrl-F matter, or the refactor cost is not worth it. CSS content-visibility: auto tells the browser to skip rendering work (style, layout, paint) for off-screen elements while keeping them in the DOM; pair it with contain-intrinsic-size: auto 44px so skipped elements still reserve estimated space and the scrollbar stays sane. The crucial difference from windowing: the nodes still exist. React still rendered all 10,000 components, memory still holds 300k nodes, and find-in-page still works because the content is real. So content-visibility rescues scrolling and initial layout (the browser engine) but does nothing for update cost (the React engine) — a keystroke that re-renders 10,000 rows is exactly as slow as before. Decision rule: browser-side cost on mostly-static content → content-visibility, one line of CSS; React-side update cost on interactive data → virtualization, a real refactor. The Hook’s table needed the refactor because typing, not just scrolling, was slow.