Virtualization and Windowing

Rendering 1,000+ items naively builds a DOM tree large enough that style and layout alone block the main thread for hundreds of milliseconds — far past the 16.7 ms frame budget at 60 fps¹. Virtualization sidesteps that by rendering only the items currently in the viewport plus a small overscan buffer, keeping the DOM at O(viewport) regardless of total list length. The trade-off you accept in exchange: more code, scroll-position bookkeeping, and a cluster of accessibility, search, and anchor-link regressions you have to engineer around.

Mental model

Virtualization is a viewport-centric rendering strategy: compute which items fall inside the visible window, render only those plus an overscan buffer, and position them with GPU-accelerated transforms instead of layout-triggering properties. The core insight: users can only see one viewport at a time, so anything else is wasted layout, paint, and memory.

Three implementation shapes dominate, plus one CSS-only alternative:

1. Fixed-height — pure arithmetic positioning when every item is the same height. Simplest, fastest, rarely matches real content.
2. Variable-height — measure as you render, cache heights, estimate the unmeasured. Production standard for dynamic content.
3. DOM recycling — keep a fixed pool of nodes; reposition and rebind their content as the user scrolls. Eliminates allocation churn.
4. CSS content-visibility: auto — defer layout/paint for off-screen elements while keeping the full DOM. Preserves find-in-page and anchor links; trades virtualization’s memory savings for a CSS-only implementation.

The constraints that shape all four:

• Frame budget. 16.67 ms per frame at 60 fps; the browser eats roughly 4 ms of that for its own work, leaving ~10–12 ms for JS, style, and layout combined².
• Compositor-only positioning. transform: translateY() runs on the compositor thread; top/margin-top triggers layout on every scroll frame³⁴.
• Measurement APIs. ResizeObserver for heights⁵, IntersectionObserver for viewport entry⁶.
• Accessibility. Screen readers see only what’s in the DOM, so virtualized content needs ARIA scaffolding (aria-setsize, aria-posinset) and explicit focus management.

When you actually need it

Two operational facts drive these thresholds:

• Layout scales with DOM size. Style recalc and layout walk the tree, so the cost grows with element count even when only a fraction is on screen.
• Memory pressure on mobile. Each DOM node carries a JS wrapper, computed style, and layout box. On low-end Android (effective JS heap of 50–100 MB), 10,000+ nodes can trigger GC pauses or out-of-memory crashes².

The reader-facing requirements that constrain the implementation:

• Scroll must feel native — no jumps, no blank flashes.
• Arrow keys, click, and focus respond well under 100 ms¹.
• Scrollbar drag to arbitrary positions must produce the right items, not a misaligned approximation.
• Cmd/Ctrl+F should find content — and this is exactly what naive virtualization breaks.

The four design paths

Path 1 — Fixed-height virtualization

When every item shares the same height, positioning is pure arithmetic. No measurement, no cache, no estimation error.

Show 3 hidden lines4  items: T[];5  itemHeight: number;6  containerHeight: number;7  overscan?: number;8  renderItem: (item: T, index: number) => React.ReactNode;9}1011function FixedVirtualizer<T>({12  items,13  itemHeight,14  containerHeight,15  overscan = 3,16  renderItem,17}: FixedVirtualizerProps<T>) {18  const [scrollTop, setScrollTop] = useState(0);1920  const startIndex = Math.max(0, Math.floor(scrollTop / itemHeight) - overscan);21  const endIndex = Math.min(22    items.length,23    Math.ceil((scrollTop + containerHeight) / itemHeight) + overscan24  );2526  const visibleItems = items.slice(startIndex, endIndex);27  const offsetY = startIndex * itemHeight;28  const totalHeight = items.length * itemHeight;Show 7 hidden lines36      <div style={{ height: totalHeight, position: 'relative' }}>37        <div style={{ transform: `translateY(${offsetY}px)` }}>38          {visibleItems.map((item, i) => (39            <div key={startIndex + i} style={{ height: itemHeight }}>40              {renderItem(item, startIndex + i)}41            </div>42          ))}43        </div>44      </div>45    </div>46  );47}

The critical line is transform: translateY() — it runs on the compositor thread without triggering layout or paint when the element is on its own compositor layer³⁴. Use top, margin-top, or position: absolute; top and you trigger a full layout pass on every scroll frame, which is the single most common reason a “virtualized” list still drops frames.

Best for log viewers, monospace text, simple data tables with uniform rows, and any list where uniform height is acceptable.

Trade-offs

• Simplest implementation; smallest bundle contribution.
• Pure-math positioning means consistent, predictable performance.
• Real content (images, variable text, expandable sections) almost never fits the fixed-height assumption.

VS Code’s editor view has historically used this shape — line-based virtualization with monospace lines that share a height, which is what makes positioning sub-millisecond on 100K+-line files. It now also supports variable line heights via decorations⁷, but the fast path is still fixed.

Path 2 — Variable-height virtualization

Items are measured as they mount via ResizeObserver; measurements feed a height cache; unmeasured items are positioned with an estimate. This is the production default for any feed-style content.

Show 5 hidden lines6  containerHeight: number7  overscan?: number8  renderItem: (item: T, index: number, measureRef: (el: HTMLElement | null) => void) => React.ReactNode9}1011function VariableVirtualizer<T>({12  items,13  estimatedItemHeight,14  containerHeight,15  overscan = 3,16  renderItem,17}: VariableVirtualizerProps<T>) {18  const [scrollTop, setScrollTop] = useState(0)19  const [heightCache, setHeightCache] = useState<Map<number, number>>(new Map())2021  const getItemOffset = (index: number): number => {22    let offset = 023    for (let i = 0; i < index; i++) {24      offset += heightCache.get(i) ?? estimatedItemHeight25    }26    return offset27  }2829  const findStartIndex = (scrollPos: number): number => {30    let low = 0,31      high = items.length - 132    while (low < high) {33      const mid = Math.floor((low + high) / 2)34      if (getItemOffset(mid + 1) <= scrollPos) {35        low = mid + 136      } else {37        high = mid38      }39    }40    return Math.max(0, low - overscan)41  }4243  const startIndex = findStartIndex(scrollTop)4445  let endIndex = startIndex46  let accumulatedHeight = 047  while (endIndex < items.length && accumulatedHeight < containerHeight + overscan * estimatedItemHeight) {48    accumulatedHeight += heightCache.get(endIndex) ?? estimatedItemHeight49    endIndex++50  }51  endIndex = Math.min(items.length, endIndex + overscan)5253  const totalHeight = getItemOffset(items.length)54  const offsetY = getItemOffset(startIndex)5556  const measureElement = useCallback(57    (index: number) => (el: HTMLElement | null) => {58      if (el) {59        const observer = new ResizeObserver(([entry]) => {Show 17 hidden lines

The flow that the code above hides — measure, cache, render, correct — is what makes variable-height feel jumpy if you don’t engineer it carefully:

The estimation problem

When the user drags the scrollbar to an arbitrary position, the virtualizer must position items it has never measured. Initial render uses estimates; if those estimates are wrong, the corrected positions cause a visible jump as ResizeObserver callbacks land. Mitigations stack:

1. Type-based estimates. If items have a discriminating type (text, image, embed, card), keep per-type averages instead of one global number.
2. Running average. Track the mean of measured heights and use it for new estimates.
3. Larger overscan in the scroll direction. Render extra items past the viewport so estimation errors correct off-screen.
4. Progressive scroll correction. Adjust scroll position smoothly rather than snapping when measurements arrive.

How ResizeObserver actually delivers

Two non-obvious facts from the spec are worth internalizing because they shape what you can do inside a measurement callback.

ResizeObserver reports content-box geometry (contentRect) by default, which excludes padding, border, and margin⁸. If your item layout depends on margins, fold them in explicitly:

1const computedStyle = getComputedStyle(element)2const marginTop = parseFloat(computedStyle.marginTop)3const marginBottom = parseFloat(computedStyle.marginBottom)4const totalHeight = entry.contentRect.height + marginTop + marginBottom

The spec prevents infinite resize loops with a depth-based delivery rule, not breadth-first: each iteration of the delivery loop only reports observations for elements deeper in the DOM tree than the shallowest element delivered in the previous iteration. If the loop terminates with skipped observations still pending, the user agent fires the ResizeObserver loop completed with undelivered notifications error and defers the rest to the next frame⁵⁸. This is why a measurement callback that mutates ancestors of the observed element typically surfaces as that error in production telemetry — and why scheduling such mutations through requestAnimationFrame (so they land in the next frame) usually fixes it.

Best for social feeds, chat with mixed media, any dynamic content where you can’t enforce a single height.

Path 3 — DOM recycling

Instead of mounting and unmounting nodes as items enter or leave the viewport, recycle a fixed pool: when an item scrolls out, its DOM node is repositioned and its content rebound to the new item.

1class DOMRecycler {2  private pool: HTMLElement[] = []3  private poolSize: number45  constructor(viewportSize: number, overscan: number) {6    this.poolSize = viewportSize + overscan * 27    this.initializePool()8  }910  private initializePool() {11    for (let i = 0; i < this.poolSize; i++) {12      const element = document.createElement("div")13      element.className = "virtual-item"14      this.pool.push(element)15    }16  }1718  recycleElement(element: HTMLElement, newItem: Item, newPosition: number) {19    element.textContent = newItem.content20    element.style.transform = `translateY(${newPosition}px)`21  }22}

Why recycling helps once mount/unmount churn is the bottleneck:

• No GC pressure. Allocation per scroll frame is the part that triggers the worst GC pauses; reusing nodes flattens that.
• Warm style cache. Reused nodes carry their cached computed style; the engine can skip work on common branches.
• Constant memory. Pool size is set up front; total list length doesn’t change it.

AG Grid uses DOM virtualization for both rows and columns — the docs explicitly call out that elements are inserted and removed as the user scrolls, with a default rowBuffer of 10 around the viewport, and that disabling virtualization “significantly increases the memory footprint and slows down the browser”. For a 100K-row grid the rendered DOM stays in the dozens, not the hundreds of thousands.

Path 4 — CSS content-visibility: auto

content-visibility tells the browser to skip rendering work for off-screen elements while keeping them in the DOM⁹.

1.list-item {2  content-visibility: auto;3  contain-intrinsic-size: 0 100px; /* placeholder size while off-screen */4}

The values:

• visible (default) — render normally.
• auto — apply size containment and skip layout/paint while off-screen; render normally when it scrolls in.
• hidden — never render contents (cheaper than display: none for show/hide because the rendering tree state is preserved).

contain-intrinsic-size is mandatory in practice for scrollable lists. Under content-visibility: auto, off-screen elements receive size containment and the browser treats their contents as if they were empty, defaulting their box to 0px. Without contain-intrinsic-size they collapse out of the layout, the scroll container shrinks, and the scrollbar position jitters as elements enter the viewport⁹¹⁰.

Browser support and Baseline status

content-visibility reached Baseline Newly Available on 2025-09-15¹¹. Per caniuse: Chrome/Edge 85+, Firefox 125+ (April 2024), Safari 18.0+ (September 2024). Older Safari has partial support; full support landed in Safari 26 in 2025.

Trade-offs vs virtualization

Use content-visibility over virtualization when the list has fewer than ~10K items, memory is not the binding constraint, find-in-page or anchor links matter, or you want the cheapest possible implementation.

The web.dev case study reports a 7× rendering improvement on a chunked travel-blog page — initial rendering time dropped from 232 ms to 30 ms after applying content-visibility: auto to article sections — without changing any DOM structure¹².

Decision framework

Browser APIs you actually use

ResizeObserver for height measurement

ResizeObserver reports element-size changes asynchronously, avoiding the synchronous layout cost of getBoundingClientRect() calls in a scroll handler⁵.

Show 2 hidden lines3    const height = entries[0].contentRect.height4    onMeasure(height)5  })67  observer.observe(element)89  return () => observer.disconnect()10}

See § How ResizeObserver actually delivers above for the depth-based loop limit and what it means for callback design.

IntersectionObserver for visibility detection

IntersectionObserver reports viewport entries and exits asynchronously, batched, and without forcing synchronous layout⁶. The canonical use in a virtualized list is a sentinel for infinite-scroll loading, not the per-item visibility bookkeeping (the virtualizer does that with arithmetic).

Show 2 hidden lines3    (entries) => {4      if (entries[0].isIntersecting) {5        onVisible()6      }7    },8    {9      rootMargin: "200px",10      threshold: 0,11    },12  )1314  observer.observe(sentinel)15  return () => observer.disconnect()16}

Why prefer it over scroll-event tracking:

• Calculations are off the main thread.
• It does not force synchronous layout the way a scroll-event handler that reads geometry does.
• Multiple intersections deliver in one callback.

requestAnimationFrame for scroll handling

scroll events fire many times per frame on touch devices and high-refresh displays. Coalescing into a single requestAnimationFrame callback prevents redundant work.

1let scheduled = false2let lastScrollTop = 034function handleScroll(e: Event) {5  lastScrollTop = (e.target as HTMLElement).scrollTop67  if (!scheduled) {8    scheduled = true9    requestAnimationFrame(() => {10      updateVisibleRange(lastScrollTop)11      scheduled = false12    })13  }14}

Pair this with { passive: true } so the browser doesn’t have to wait for preventDefault() decisions before scrolling.

Failure modes and edge cases

Scroll-position jumping

Symptom. Dragging the scrollbar to an arbitrary position briefly shows the wrong items, then snaps to the right ones.

Root cause. Unmeasured items used estimated heights; the estimates were wrong; corrected measurements arrive a frame or two later via ResizeObserver.

1const heightEstimates: Record<ItemType, number> = {2  text: 60,3  image: 300,4  video: 400,5  card: 150,6}78function estimateHeight(item: Item): number {9  return heightEstimates[item.type] ?? 10010}1112let totalMeasured = 013let measurementCount = 01415function updateEstimate(measuredHeight: number) {16  totalMeasured += measuredHeight17  measurementCount++18}1920function getEstimate(): number {21  return measurementCount > 0 ? totalMeasured / measurementCount : defaultEstimate22}

Type-based estimates plus a running average is the floor of what production libraries do; layered on top, they keep a wider overscan in the scroll direction so corrections happen off-screen.

Keyboard focus loss

Show 3 hidden lines4  const [focusedIndex, setFocusedIndex] = useState<number | null>(null)5  const itemRefs = useRef<Map<number, HTMLElement>>(new Map())67  const handleKeyDown = useCallback(8    (e: KeyboardEvent) => {9      if (e.key === "ArrowDown" && focusedIndex !== null) {10        setFocusedIndex(focusedIndex + 1)11      } else if (e.key === "ArrowUp" && focusedIndex !== null) {12        setFocusedIndex(Math.max(0, focusedIndex - 1))13      }14    },15    [focusedIndex],16  )1718  useEffect(() => {19    if (focusedIndex !== null && focusedIndex >= visibleRange.start && focusedIndex <= visibleRange.end) {20      itemRefs.current.get(focusedIndex)?.focus()21    }22  }, [focusedIndex, visibleRange])2324  return { focusedIndex, setFocusedIndex, itemRefs, handleKeyDown }Show 1 hidden line

Screen-reader semantics

Screen readers navigate the DOM. Virtualized items are not in the DOM until they enter the viewport, so a virtualized list looks much shorter to assistive tech than it actually is. The fix is two separate ARIA pieces, used for different things.

1. List semantics — make the visible items advertise the full set. When the complete set of items is not all present in the DOM, every rendered item must carry aria-setsize (the full count) and aria-posinset (its position within that count) so the screen reader can announce “item 42 of 10,000”¹³:

1<div role="list" aria-label="Messages">2  <div role="listitem" aria-setsize="10000" aria-posinset="42">Item 42 of 10,000</div>3  <!-- one element per visible (rendered) item -->4</div>

2. Live-region announcements — only for genuinely new content. Wrapping the list itself in aria-live is the most common mistake: every item that mounts during scroll gets announced, drowning the user in noise. Use a separate, visually hidden live region for events the user actually wants narrated (a new chat message arriving, a new search result loading at the top), and leave the list semantics alone¹⁴:

1<!-- separate region, lives outside the virtualized list -->2<div aria-live="polite" aria-relevant="additions" class="visually-hidden">3  <!-- write a one-line summary here when a new message arrives -->4</div>

Focus management goes alongside this: use a roving tabindex (one item is tabindex="0", the rest are -1) so the keyboard user lands on the active item, not the container, and so virtualization can swap nodes without losing the tab order.

Find-in-page

Browser Ctrl+F / Cmd+F searches only the rendered DOM. Virtualized items aren’t in it. Three options, in order of cost:

1. Switch to content-visibility when the list size allows it. Native find-in-page comes back for free.

2. Custom search UI. Implement an in-app search that scans the underlying data, then scrollToIndex on a hit.

   custom-search.ts

   1function searchAndScroll(query: string, items: Item[], virtualizer: Virtualizer) {2  const matchIndex = items.findIndex((item) => item.content.toLowerCase().includes(query.toLowerCase()))3  if (matchIndex !== -1) {4    virtualizer.scrollToIndex(matchIndex, { align: "center" })5  }6}

3. Tell the user. A small notice that browser find won’t reach all items is worse than fixing it but better than a silent regression.

Bidirectional scroll (chat history)

Chat lists prepend history at the top while new messages arrive at the bottom. Both directions modify the list, and the user must not see the viewport jump.

Scroll anchoring — when items are added above the viewport, adjust scroll position to keep the visible content stationary:

1function addHistoryItems(newItems: Item[], existingItems: Item[]) {2  const scrollContainer = containerRef.current3  const currentScrollTop = scrollContainer.scrollTop4  const anchorItem = findFirstVisibleItem()5  const anchorOffset = getItemOffset(anchorItem.index)67  const combined = [...newItems, ...existingItems]89  requestAnimationFrame(() => {10    const newAnchorOffset = getItemOffset(anchorItem.index + newItems.length)11    const adjustment = newAnchorOffset - anchorOffset12    scrollContainer.scrollTop = currentScrollTop + adjustment13  })14}

This is the dominant pattern in production chat clients (Discord, Slack, Telegram web). The browser also has a built-in CSS overflow-anchor for non-virtualized layouts, but virtualizers manage scroll position imperatively and usually disable it.

Dynamic content (images loading)

Images without intrinsic dimensions cause layout shift on load, invalidating cached heights. Reserve space with aspect-ratio so the layout box is correct before pixels arrive:

1.image-container {2  aspect-ratio: 16 / 9;3  width: 100%;4}56.image-container img {7  width: 100%;8  height: 100%;9  object-fit: cover;10}

If images are unpredictable in size, re-measure on load and write the corrected height back into the cache.

Performance optimization

Overscan

Overscan renders extra items past the viewport so the user does not see blank space during fast scrolling. Higher overscan is smoother but renders more work per frame.

Direction-aware overscan — extra in the scroll direction, less behind — is a cheap win:

1function calculateOverscan(scrollDirection: "up" | "down") {2  return {3    overscanBefore: scrollDirection === "up" ? 5 : 2,4    overscanAfter: scrollDirection === "down" ? 5 : 2,5  }6}

Compositor-only positioning

1/* Compositor only */2.virtual-item {3  transform: translateY(var(--offset));4  will-change: transform;5}67/* Triggers layout */8.virtual-item-bad {9  position: absolute;10  top: var(--offset);11}

will-change: transform hints to the browser to promote the element to its own compositor layer in advance¹⁵. Use it sparingly: MDN explicitly warns it is “intended to be used as a last resort, in order to try to deal with existing performance problems”¹⁵. Promoting every item costs memory and can hurt performance on memory-constrained devices.

Memory management for very large lists

When the list reaches millions of items, the height cache itself becomes the bottleneck. Segment-based caching with LRU eviction keeps it bounded:

1class SegmentedHeightCache {2  private segments: Map<number, Map<number, number>> = new Map()3  private segmentSize = 10004  private maxSegments = 1056  get(index: number): number | undefined {7    const segmentId = Math.floor(index / this.segmentSize)8    const segment = this.segments.get(segmentId)9    return segment?.get(index)10  }1112  set(index: number, height: number) {13    const segmentId = Math.floor(index / this.segmentSize)14    if (!this.segments.has(segmentId)) {15      if (this.segments.size >= this.maxSegments) {16        this.evictOldest()17      }18      this.segments.set(segmentId, new Map())19    }20    this.segments.get(segmentId)!.set(index, height)21  }2223  private evictOldest() {24    const firstKey = this.segments.keys().next().value25    this.segments.delete(firstKey)26  }27}

Grid virtualization

Grid virtualization is two-dimensional: window both rows and columns simultaneously.

Show 3 hidden lines4  rowHeight: number5  columnWidth: number6  containerWidth: number7  containerHeight: number8}910function calculateVisibleGrid({11  scrollTop,12  scrollLeft,13  rowHeight,14  columnWidth,15  containerWidth,16  containerHeight,17  rowCount,18  columnCount,19}: GridVirtualizerProps & { scrollTop: number; scrollLeft: number }) {20  const startRow = Math.floor(scrollTop / rowHeight)21  const endRow = Math.min(rowCount, Math.ceil((scrollTop + containerHeight) / rowHeight) + 1)2223  const startCol = Math.floor(scrollLeft / columnWidth)24  const endCol = Math.min(columnCount, Math.ceil((scrollLeft + containerWidth) / columnWidth) + 1)2526  return {27    visibleRows: { start: startRow, end: endRow },28    visibleCols: { start: startCol, end: endCol },29  }30}

The differences from list virtualization that bite:

• Header sync. Column headers must scroll horizontally with the body; row headers must scroll vertically. Most teams sync them imperatively in the same scroll handler.
• Cell selection. Multi-cell selection requires tracking 2D ranges and rendering selection highlights efficiently — usually via overlay layers, not per-cell DOM.
• Column resize. Width changes invalidate every cached column position; the recompute is more expensive than row-height updates because it touches the horizontal axis formula for every visible row.

Reference implementations

Discord — chat with rich, mixed content

Discord stores trillions of messages in ScyllaDB after migrating off Cassandra in 2022; their published architecture covers the storage layer in detail but not the client message-rendering implementation. In practice, large chat clients of this shape combine the patterns documented above: variable-height virtualization with type-based estimates, scroll anchoring on history loads, and a separate fast path for “jump to message” that uses estimation rather than measurement.

Figma — non-DOM canvas virtualization

Figma’s renderer was WebGL-based since 2015 and migrated to WebGPU in September 2025, built on the Dawn implementation that backs Chromium WebGPU support — which itself shipped in Chrome 113 in April 2023. The “virtualization” in this architecture is not a DOM concern at all: a spatial index (R-tree) selects which canvas objects to upload to the GPU at the current viewport and zoom, and level-of-detail simplification keeps far-away objects cheap. The DOM never sees the millions of objects; only the rendered canvas does.

Monaco / VS Code — editor virtualization

The editor uses line-based virtualization. The fast path historically assumes uniform line heights, which is what enables sub-millisecond scroll-position math on 100K+-line files. Variable line heights are now supported per-line via editor decorations; the line height for a row is the maximum of decoration heights applied to it.

For very large files, VS Code selectively disables features (editor.largeFileOptimizations) — syntax highlighting, code folding, the minimap — trading capability for responsiveness. This is the underrated lesson from VS Code: virtualization alone is not enough at the extreme; you also need to know which features are safe to drop.

Library landscape

The numbers below are the gzipped install sizes reported by Bundlephobia at the time of writing — for production budgeting, regenerate them against the version you ship.

react-window

Authored by Brian Vaughn, former React core team. Designed as a smaller, more focused successor to react-virtualized. Components: FixedSizeList, VariableSizeList, FixedSizeGrid, VariableSizeGrid. Reported bundle size ~6.5 kB minified+gzipped (v2.x).

Best for teams who want a small, well-maintained React solution for the common shapes.

react-virtuoso

Specialized for variable-height content with automatic measurement. Built around ResizeObserver-driven height tracking, has first-class support for prepend (chat) and grouped lists with sticky headers. Reported bundle size ~3.5 kB minified+gzipped.

Best for social feeds, chat, anywhere heights vary unpredictably.

@tanstack/virtual

Framework-agnostic core with adapters for React, Vue, Svelte, and Solid, maintained by Tanner Linsley. The core handles the math; the adapter handles framework integration. Reported bundle size for @tanstack/react-virtual is well under 1 kB minified+gzipped — most of the perceived size in apps comes from the adapter and the surrounding API surface.

Best for teams who need virtualization across multiple frameworks or want fine-grained control over measurement and rendering.

Quick comparison

Practical takeaways

• Default to content-visibility: auto when the list fits in memory and find-in-page or anchor links matter. It is the cheapest implementation and preserves browser semantics.
• Pick fixed-height virtualization only when the design genuinely supports uniform heights — log viewers, monospace editors, simple grids.
• Pick variable-height virtualization for almost everything else. Pair it with type-based estimates and a wider scroll-direction overscan to absorb estimation error off-screen.
• Reach for DOM recycling when you measure GC pauses during continuous scroll and the allocation churn is the cause.
• Always use transform: translateY() for positioning. top / margin-top is the most common cause of “virtualized but still janky” lists.
• Coalesce scroll handlers through requestAnimationFrame and pass { passive: true } to the listener.
• Treat focus and ARIA as part of the virtualizer, not as a follow-up. The <virtual-scroller> standardization effort was archived; the application owns this.
• Benchmark against real data shapes, not synthetic uniform lists. Estimation error and image loads dominate real performance — synthetic benchmarks rarely surface them.

Appendix

Prerequisites

• Browser rendering pipeline (style → layout → paint → composite).
• React or another component framework, for the library examples.
• Big-O intuition.

Terminology

References