Virtualization and Windowing

Rendering large lists (1,000+ items) without virtualization creates a DOM tree so large that layout calculations alone can block the main thread for hundreds of milliseconds. Virtualization solves this by rendering only visible items plus a small buffer, keeping DOM node count constant regardless of list size. The trade-off: implementation complexity for consistent O(viewport) rendering performance.

Abstract

Virtualization is a viewport-centric rendering strategy: calculate which items are visible, render only those plus a buffer (overscan), and position them using GPU-accelerated transforms. The core insight is that users can only see viewport-sized content at any moment—rendering everything else is wasted work.

Three implementation approaches exist:

1. Fixed-height: Pure math-based positioning when all items are identical height. Simplest, fastest, but rarely applicable to real content.
2. Variable-height: Measure items as they render, cache heights, estimate unmeasured items. Production standard for dynamic content.
3. DOM recycling: Reuse DOM nodes as items scroll out, updating content rather than creating/destroying elements.

Critical constraints shape the design:

• Frame budget: 16ms per frame for 60fps, ~12ms after browser overhead
• Transform positioning: GPU-accelerated translateY() vs layout-triggering top
• Measurement APIs: ResizeObserver for heights, IntersectionObserver for visibility
• Accessibility: Screen readers require ARIA live regions; keyboard navigation requires focus management

A newer alternative, CSS content-visibility: auto, defers rendering while keeping full DOM—enabling browser find-in-page and anchor links that virtualization breaks.

The Challenge

Browser Constraints

The browser’s rendering pipeline processes elements sequentially:

1. Style - Match CSS rules to elements
2. Layout - Calculate element geometry (expensive, proportional to DOM size)
3. Paint - Fill pixels for colors, text, shadows
4. Composite - Assemble layers, apply GPU transforms

Layout is the bottleneck. As documented in Chrome DevTools performance analysis, layout time scales with DOM size because the engine must resolve every element’s position relative to its ancestors and siblings.

Main thread budget: At 60fps, each frame has 16ms total. The browser consumes ~4ms for its own work, leaving 10-12ms for JavaScript execution, style recalculation, and layout combined. A single layout pass on 1,000 elements can exceed this entirely.

Memory pressure: Each DOM node consumes memory for its JavaScript wrapper, style data, and layout information. On low-end mobile devices with 50-100MB practical limits, 10,000+ nodes can trigger garbage collection pauses or crashes.

When Virtualization Becomes Necessary

User Experience Requirements

• Perceived smoothness: Scroll must feel native (60fps, no jumps)
• Instant response: Arrow key navigation, click handling under 100ms
• Scroll position stability: Jumping to arbitrary positions via scrollbar must work
• Find-in-page: Users expect Cmd/Ctrl+F to search all content (virtualization breaks this)

Design Paths

Path 1: Fixed-Height Virtualization

How it works:

When all items share identical height, positioning is pure arithmetic—no measurement required.

3 collapsed lines
1
import { useState, useCallback } from 'react';
2

3
interface FixedVirtualizerProps<T> {
4
  items: T[];
5
  itemHeight: number;
6
  containerHeight: number;
7
  overscan?: number;
8
  renderItem: (item: T, index: number) => React.ReactNode;
9
}
10

11
function FixedVirtualizer<T>({
12
  items,
13
  itemHeight,
14
  containerHeight,
15
  overscan = 3,
16
  renderItem,
17
}: FixedVirtualizerProps<T>) {
18
  const [scrollTop, setScrollTop] = useState(0);
19

20
  // Calculate visible range using arithmetic only
21
  const startIndex = Math.max(0, Math.floor(scrollTop / itemHeight) - overscan);
22
  const endIndex = Math.min(
23
    items.length,
24
    Math.ceil((scrollTop + containerHeight) / itemHeight) + overscan
25
  );
26

27
  const visibleItems = items.slice(startIndex, endIndex);
28
  const offsetY = startIndex * itemHeight;
7 collapsed lines
29
  const totalHeight = items.length * itemHeight;
30

31
  const handleScroll = useCallback((e: React.UIEvent<HTMLDivElement>) => {
32
    setScrollTop(e.currentTarget.scrollTop);
33
  }, []);
34

35
  return (
36
    <div style={{ height: containerHeight, overflow: 'auto' }} onScroll={handleScroll}>
37
      <div style={{ height: totalHeight, position: 'relative' }}>
38
        <div style={{ transform: `translateY(${offsetY}px)` }}>
39
          {visibleItems.map((item, i) => (
40
            <div key={startIndex + i} style={{ height: itemHeight }}>
41
              {renderItem(item, startIndex + i)}
42
            </div>
43
          ))}
44
        </div>
45
      </div>
46
    </div>
47
  );
48
}

Why transform instead of top:

• transform: translateY() is compositor-only—GPU handles it without triggering layout
• top or margin-top triggers full layout recalculation on every scroll frame
• This single choice can be the difference between 60fps and 15fps scrolling

Performance characteristics:

Best for:

• Log viewers with monospace text
• Simple data tables with uniform rows
• Chat applications with text-only messages
• Any list where enforcing fixed height is acceptable

Trade-offs:

• ✅ Simplest implementation, smallest bundle contribution
• ✅ Predictable performance—pure math, no measurement
• ✅ No height cache memory overhead
• ❌ Real content (images, variable text, expandable sections) rarely fits
• ❌ Forces design constraints on UI

Real-world example:

VS Code’s minimap uses fixed-height line rendering. Each line is represented at a consistent pixel height regardless of content wrapping in the main editor. This enables sub-millisecond position calculations for files with 100K+ lines.

Path 2: Variable-Height Virtualization

How it works:

Items are measured as they render using ResizeObserver. A height cache stores measurements indexed by item. Unmeasured items use an estimated height.

5 collapsed lines
1
import { useState, useEffect, useRef, useCallback } from "react"
2

3
interface VariableVirtualizerProps<T> {
4
  items: T[]
5
  estimatedItemHeight: number
6
  containerHeight: number
7
  overscan?: number
8
  renderItem: (item: T, index: number, measureRef: (el: HTMLElement | null) => void) => React.ReactNode
9
}
10

11
function 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())
20

21
  // Calculate positions with measured or estimated heights
22
  const getItemOffset = (index: number): number => {
23
    let offset = 0
24
    for (let i = 0; i < index; i++) {
25
      offset += heightCache.get(i) ?? estimatedItemHeight
26
    }
27
    return offset
28
  }
29

30
  // Binary search to find start index from scroll position
31
  const findStartIndex = (scrollPos: number): number => {
32
    let low = 0,
33
      high = items.length - 1
34
    while (low < high) {
35
      const mid = Math.floor((low + high) / 2)
36
      if (getItemOffset(mid + 1) <= scrollPos) {
37
        low = mid + 1
38
      } else {
39
        high = mid
40
      }
41
    }
42
    return Math.max(0, low - overscan)
43
  }
44

45
  const startIndex = findStartIndex(scrollTop)
46

47
  // Find end index by accumulating heights until we exceed viewport
48
  let endIndex = startIndex
49
  let accumulatedHeight = 0
50
  while (endIndex < items.length && accumulatedHeight < containerHeight + overscan * estimatedItemHeight) {
51
    accumulatedHeight += heightCache.get(endIndex) ?? estimatedItemHeight
52
    endIndex++
53
  }
54
  endIndex = Math.min(items.length, endIndex + overscan)
55

56
  const totalHeight = getItemOffset(items.length)
57
  const offsetY = getItemOffset(startIndex)
58

59
  // Measure items as they render
21 collapsed lines
60
  const measureElement = useCallback(
61
    (index: number) => (el: HTMLElement | null) => {
62
      if (el) {
63
        const observer = new ResizeObserver(([entry]) => {
64
          const height = entry.contentRect.height
65
          setHeightCache((prev) => {
66
            if (prev.get(index) === height) return prev
67
            const next = new Map(prev)
68
            next.set(index, height)
69
            return next
70
          })
71
        })
72
        observer.observe(el)
73
        return () => observer.disconnect()
74
      }
75
    },
76
    [],
77
  )
78

79
  // ... scroll handler and render logic
80
}

The estimation problem:

When users drag the scrollbar to an arbitrary position, the virtualizer must render items that haven’t been measured. Initial render uses estimates, which may be wrong—causing a visible “jump” as measurements arrive and positions correct.

Mitigation strategies:

1. Running average: Track average measured height, use for estimates
2. Type-based estimates: If items have types (text, image, card), use type-specific averages
3. Larger buffers: Overscan more items to catch estimation errors before they’re visible
4. Progressive correction: Animate position corrections rather than snapping

Performance characteristics:

Best for:

• Social media feeds with mixed content
• Chat applications with images, embeds, reactions
• Any dynamic content where height enforcement is impossible

Trade-offs:

• ✅ Handles real-world content naturally
• ✅ Smooth scroll with proper buffering
• ❌ Height cache grows with items scrolled through
• ❌ Scroll position jumps possible on fast scrollbar drag
• ❌ Complex implementation with many edge cases

Real-world example:

Twitter/X uses variable-height virtualization for the home timeline. Tweets contain text, images, videos, polls, and embedded content—all with different heights. They mitigate scroll jumps by maintaining a larger buffer in the scroll direction and using type-based height estimates (tweets with images get higher estimates).

Path 3: DOM Recycling

How it works:

Instead of creating and destroying DOM elements as items enter/exit the viewport, a fixed pool of elements is reused. When an item scrolls out, its DOM node is repositioned and its content updated with the new item.

1
// Conceptual representation - production implementations are more complex
2
class DOMRecycler {
3
  private pool: HTMLElement[] = []
4
  private poolSize: number
5

6
  constructor(viewportSize: number, overscan: number) {
7
    // Fixed pool size based on viewport, never grows
8
    this.poolSize = viewportSize + overscan * 2
9
    this.initializePool()
10
  }
11

12
  private initializePool() {
13
    for (let i = 0; i < this.poolSize; i++) {
14
      const element = document.createElement("div")
15
      element.className = "virtual-item"
16
      this.pool.push(element)
17
    }
18
  }
19

20
  // When item scrolls out of view
21
  recycleElement(element: HTMLElement, newItem: Item, newPosition: number) {
22
    // Reuse same DOM node - update content, reposition
23
    element.textContent = newItem.content
24
    element.style.transform = `translateY(${newPosition}px)`
25
    // No DOM creation/destruction - just property updates
26
  }
27
}

Why recycling improves performance:

• No GC pressure: Element creation allocates memory; destruction triggers garbage collection
• Warm caches: Reused elements have cached style computations
• Predictable memory: Pool size is constant regardless of list length

Performance characteristics:

Real-world example:

AG Grid uses DOM recycling for both row and cell elements in data grids. When scrolling a 100K-row grid, the same ~50 row elements are reused continuously. Their documentation notes this eliminates GC pauses that would otherwise occur every few seconds during continuous scrolling.

Path 4: CSS content-visibility (Newer Alternative)

How it works:

The content-visibility CSS property 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; /* Width height estimate */
4
}

Values:

• visible (default): Render normally
• auto: Skip rendering when off-screen, render when visible
• hidden: Never render (like display: none but preserves layout space)

Critical requirement—contain-intrinsic-size:

Without this, off-screen elements contribute zero height to layout, collapsing the scrollbar. The browser needs height estimates to maintain proper scroll dimensions.

Browser support (as of 2025):

All major browsers (Chrome 85+, Firefox 109+, Safari 17.4+) support content-visibility. Edge cases remain in Safari for nested scrolling contexts.

Performance characteristics:

Trade-offs vs virtualization:

When to use content-visibility over virtualization:

• Lists under 10,000 items where memory isn’t critical
• When find-in-page is required
• When anchor navigation is required
• When simplicity is prioritized over minimal memory
• Progressive enhancement scenarios

Real-world example:

web.dev reports a 7x rendering performance improvement on the Chrome DevRel blog by applying content-visibility: auto to article sections. The full article DOM exists for search engines and find-in-page, but off-screen sections don’t consume paint time.

Decision Matrix

Decision Framework

Browser APIs for Virtualization

ResizeObserver for Height Measurement

ResizeObserver reports element size changes asynchronously, avoiding the performance penalty of synchronous getBoundingClientRect() calls.

2 collapsed lines
1
// Height measurement pattern used by react-virtuoso
2
function measureItemHeight(element: HTMLElement, onMeasure: (height: number) => void): () => void {
3
  const observer = new ResizeObserver((entries) => {
4
    // contentRect excludes padding and border
5
    const height = entries[0].contentRect.height
6
    onMeasure(height)
7
  })
8

9
  observer.observe(element)
10

11
  // Cleanup function
12
  return () => observer.disconnect()
13
}

Critical detail—what ResizeObserver measures:

ResizeObserver’s contentRect reports the content box (excluding padding, border, margin). If items have margins, add them manually:

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

Infinite loop prevention:

The ResizeObserver spec prevents infinite loops by delivering notifications breadth-first. If observing an element triggers its resize (e.g., changing its content), the callback won’t fire again in the same frame—subsequent changes are delivered in the next frame.

IntersectionObserver for Visibility Detection

IntersectionObserver detects when elements enter or exit the viewport without triggering layout calculations.

2 collapsed lines
1
// Sentinel pattern for infinite scroll loading
2
function setupLoadMoreTrigger(sentinel: HTMLElement, onVisible: () => void) {
3
  const observer = new IntersectionObserver(
4
    (entries) => {
5
      if (entries[0].isIntersecting) {
6
        onVisible() // Load more items
7
      }
8
    },
9
    {
10
      rootMargin: "200px", // Trigger 200px before visible
11
      threshold: 0,
12
    },
13
  )
14

15
  observer.observe(sentinel)
16
  return () => observer.disconnect()
17
}

Why IntersectionObserver over scroll events:

• Off main thread: Calculations happen asynchronously
• No layout thrashing: Doesn’t force synchronous layout
• Batched: Multiple intersections delivered in one callback

requestAnimationFrame for Scroll Handling

Scroll events fire many times per frame. RAF throttles updates to the frame rate naturally.

1
let scheduled = false
2
let lastScrollTop = 0
3

4
function handleScroll(e: Event) {
5
  lastScrollTop = (e.target as HTMLElement).scrollTop
6

7
  if (!scheduled) {
8
    scheduled = true
9
    requestAnimationFrame(() => {
10
      updateVisibleRange(lastScrollTop)
11
      scheduled = false
12
    })
13
  }
14
}

Why this matters:

On a 144Hz display, scroll events might fire 144+ times per second. Without RAF throttling, you’d recalculate visible items on every event—most of which occur between frames and waste CPU cycles.

Edge Cases and Failure Modes

Scroll Position Jumping

Symptom: When dragging the scrollbar to an arbitrary position, content briefly shows wrong items before correcting.

Root cause: Unmeasured items use estimated heights. If estimates are wrong, calculated scroll positions are wrong.

Mitigation strategies:

1
// Strategy 1: Type-based estimates
2
const heightEstimates: Record<ItemType, number> = {
3
  text: 60,
4
  image: 300,
5
  video: 400,
6
  card: 150,
7
}
8

9
function estimateHeight(item: Item): number {
10
  return heightEstimates[item.type] ?? 100
11
}
12

13
// Strategy 2: Running average
14
let totalMeasured = 0
15
let measurementCount = 0
16

17
function updateEstimate(measuredHeight: number) {
18
  totalMeasured += measuredHeight
19
  measurementCount++
20
}
21

22
function getEstimate(): number {
23
  return measurementCount > 0 ? totalMeasured / measurementCount : defaultEstimate
24
}

Keyboard Navigation and Focus Management

Critical accessibility failure: When a focused item scrolls out of the viewport and is unmounted, focus is lost. Screen reader users lose their position entirely.

Solution: Track logical focus (item index) separately from DOM focus. When scrolling brings the focused item back into view, restore DOM focus.

3 collapsed lines
1
import { useState, useEffect, useRef, useCallback } from "react"
2

3
function useFocusManagement(visibleRange: { start: number; end: number }) {
4
  const [focusedIndex, setFocusedIndex] = useState<number | null>(null)
5
  const itemRefs = useRef<Map<number, HTMLElement>>(new Map())
6

7
  // Track which item should have focus (logical, not DOM)
8
  const handleKeyDown = useCallback(
9
    (e: KeyboardEvent) => {
10
      if (e.key === "ArrowDown" && focusedIndex !== null) {
11
        setFocusedIndex(focusedIndex + 1)
12
      } else if (e.key === "ArrowUp" && focusedIndex !== null) {
13
        setFocusedIndex(Math.max(0, focusedIndex - 1))
14
      }
15
    },
16
    [focusedIndex],
17
  )
18

19
  // Restore DOM focus when focused item becomes visible
20
  useEffect(() => {
21
    if (focusedIndex !== null && focusedIndex >= visibleRange.start && focusedIndex <= visibleRange.end) {
22
      itemRefs.current.get(focusedIndex)?.focus()
23
    }
24
  }, [focusedIndex, visibleRange])
3 collapsed lines
25

26
  return { focusedIndex, setFocusedIndex, itemRefs, handleKeyDown }
27
}

Screen Reader Accessibility

Fundamental problem: Screen readers navigate the DOM. Virtualized content doesn’t exist in the DOM.

ARIA live regions: Announce content changes to screen readers.

1
<div role="list" aria-label="Messages" aria-live="polite" aria-relevant="additions">
2
  <!-- Virtualized items here -->
3
  <!-- Screen reader announces when new items are added -->
4
</div>

ARIA attributes for virtualized lists:

1
<div role="listitem" aria-setsize="10000" aria-posinset="42">Item 42 of 10,000</div>

Ongoing standards work: The WICG (Web Incubator Community Group) is developing a <virtual-scroller> web component to provide native browser support for virtualization with built-in accessibility.

Find-in-Page Limitations

Hard constraint: Browser’s Ctrl+F/Cmd+F searches only the visible DOM. Virtualized items don’t exist in the DOM.

Solutions:

1. Custom search UI: Implement application-level search that queries data, calculates positions, and scrolls to results

1
function searchAndScroll(query: string, items: Item[], virtualizer: Virtualizer) {
2
  const matchIndex = items.findIndex((item) => item.content.toLowerCase().includes(query.toLowerCase()))
3

4
  if (matchIndex !== -1) {
5
    virtualizer.scrollToIndex(matchIndex, { align: "center" })
6
  }
7
}

2. Warning UI: Display a notice explaining that browser search won’t find all content

3. content-visibility alternative: For lists under ~10K items where find-in-page is critical, use CSS content-visibility: auto instead of virtualization

Bidirectional Scrolling (Chat Interfaces)

Unique challenge: Chat interfaces load history when scrolling up and receive new messages at the bottom. Both directions modify the list, and scroll position must be preserved.

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

1
function addHistoryItems(newItems: Item[], existingItems: Item[]) {
2
  // Record current scroll position and reference item
3
  const scrollContainer = containerRef.current
4
  const currentScrollTop = scrollContainer.scrollTop
5
  const anchorItem = findFirstVisibleItem()
6
  const anchorOffset = getItemOffset(anchorItem.index)
7

8
  // Add items to beginning
9
  const combined = [...newItems, ...existingItems]
10

11
  // After render, adjust scroll to maintain anchor position
12
  requestAnimationFrame(() => {
13
    const newAnchorOffset = getItemOffset(anchorItem.index + newItems.length)
14
    const adjustment = newAnchorOffset - anchorOffset
15
    scrollContainer.scrollTop = currentScrollTop + adjustment
16
  })
17
}

Reverse infinite scroll: Discord’s message list uses this pattern. Scrolling to the top triggers history loading, with scroll position adjusted so the user doesn’t notice items being prepended.

Dynamic Content (Images Loading)

Problem: Images without dimensions cause layout shift when they load, invalidating cached heights.

Solutions:

1. Aspect ratio CSS: Reserve space before image loads

1
.image-container {
2
  aspect-ratio: 16 / 9;
3
  width: 100%;
4
}
5

6
.image-container img {
7
  width: 100%;
8
  height: 100%;
9
  object-fit: cover;
10
}

2. Re-measure on load: Update height cache when images complete

2 collapsed lines
1
function ImageItem({ item, onHeightChange }: Props) {
2
  const ref = useRef<HTMLDivElement>(null);
3

4
  const handleImageLoad = () => {
5
    if (ref.current) {
6
      onHeightChange(ref.current.offsetHeight);
7
    }
8
  };
9

10
  return (
11
    <div ref={ref}>
12
      <img src={item.imageUrl} onLoad={handleImageLoad} />
13
    </div>
14
  );
15
}

Performance Optimization

Overscan Configuration

Overscan renders additional items beyond the viewport to prevent blank areas during fast scrolling.

Trade-off: Higher overscan = smoother scrolling but more rendering work per frame.

Direction-aware overscan: Render more items in the scroll direction for better perceived smoothness.

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

Scroll Event Handling Strategies

RAF throttling (recommended):

1
let rafId: number | null = null
2

3
function handleScroll(e: Event) {
4
  if (rafId === null) {
5
    rafId = requestAnimationFrame(() => {
6
      updateVisibleItems()
7
      rafId = null
8
    })
9
  }
10
}

Passive event listeners: Improve scroll performance by indicating the handler won’t call preventDefault().

1
container.addEventListener("scroll", handleScroll, { passive: true })

GPU-Accelerated Positioning

Use transforms, not layout-triggering properties:

1
/* ✅ GPU-accelerated */
2
.virtual-item {
3
  transform: translateY(var(--offset));
4
  will-change: transform; /* Hint to browser */
5
}
6

7
/* ❌ Triggers layout */
8
.virtual-item {
9
  position: absolute;
10
  top: var(--offset);
11
}

will-change caveat: MDN warns that will-change is “intended to be used as a last resort.” Excessive use creates too many compositor layers, consuming memory and potentially hurting performance. Use selectively on elements that will actually animate.

Memory Management for Large Lists

Height cache strategy: For lists with millions of items, storing every height becomes problematic.

Segment-based caching: Store heights in segments, evict old segments using LRU.

1
class SegmentedHeightCache {
2
  private segments: Map<number, Map<number, number>> = new Map()
3
  private segmentSize = 1000
4
  private maxSegments = 10
5

6
  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
  }
11

12
  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
  }
22

23
  private evictOldest() {
24
    const firstKey = this.segments.keys().next().value
25
    this.segments.delete(firstKey)
26
  }
27
}

Grid Virtualization

Two-Dimensional Windowing

Grid virtualization requires windowing both rows AND columns simultaneously.

3 collapsed lines
1
interface GridVirtualizerProps {
2
  rowCount: number
3
  columnCount: number
4
  rowHeight: number
5
  columnWidth: number
6
  containerWidth: number
7
  containerHeight: number
8
}
9

10
function 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)
22

23
  const startCol = Math.floor(scrollLeft / columnWidth)
24
  const endCol = Math.min(columnCount, Math.ceil((scrollLeft + containerWidth) / columnWidth) + 1)
25

26
  return {
27
    visibleRows: { start: startRow, end: endRow },
28
    visibleCols: { start: startCol, end: endCol },
29
  }
30
}

Grid-Specific Challenges

Header synchronization: Column headers must scroll horizontally with the body; row headers must scroll vertically.

1
// Sync column header horizontal scroll with body
2
function syncHeaders(bodyScrollLeft: number, bodyScrollTop: number) {
3
  columnHeaderRef.current.scrollLeft = bodyScrollLeft
4
  rowHeaderRef.current.scrollTop = bodyScrollTop
5
}

Cell selection: Multi-cell selection requires tracking 2D ranges and rendering selection highlights efficiently.

Column resizing: When column widths change, all cached position calculations must be invalidated—more expensive than row height changes because it affects the horizontal axis formula.

Real-World Implementations

Discord: Message Virtualization

Challenge: Millions of messages across servers, with rich content (embeds, reactions, replies).

Architecture:

• Backend: ScyllaDB for message storage (replaced Cassandra for better latency)
• Frontend: Custom virtualization with DOM recycling
• Real-time: Elixir processes for WebSocket coordination

Virtualization approach:

• Fixed-ish heights: Most messages have predictable heights
• Type-based estimation for embeds, images
• Bidirectional scrolling for history loading
• Scroll anchoring when new messages arrive

Key insight: Discord separates “jump to message” (scrollbar drag) from “scroll to load more” (reaching boundaries). Jump uses estimation; boundary loading measures precisely.

Figma: Canvas Virtualization

Challenge: Infinite canvas with millions of objects at arbitrary zoom levels.

Architecture:

• Rendering: WebGL (now WebGPU in Chrome 127+)
• Spatial indexing: R-tree for visible object queries
• Level-of-detail: Simplify distant objects

Key insight: Figma doesn’t use DOM virtualization—they bypass the DOM entirely with WebGL. The “virtualization” is which objects to send to the GPU based on the current viewport and zoom level.

Outcome: 60fps with 100K+ objects, 50ms initial render for complex files.

VS Code: Editor Virtualization

Challenge: Files with 100K+ lines, syntax highlighting, code folding, minimap.

Approach:

• Line-based virtualization with fixed heights (monospace font)
• Incremental tokenization for syntax highlighting
• Minimap uses fixed-height representation

Large file optimizations (editor.largeFileOptimizations):

• Disable syntax highlighting above threshold
• Disable code folding computation
• Disable minimap rendering

Key insight: VS Code selectively disables features as file size increases, trading functionality for responsiveness.

Slack: Hybrid Virtual Scrollbar

Challenge: Message history spanning years, with mixed content types.

Approach:

• True overflow scrolling (native scrollbar behavior)
• Custom virtual scrollbar UI overlaid
• Backend pagination with cursors

Key insight: Rather than reimplementing scroll physics, Slack uses the browser’s native scrolling and only virtualizes the scrollbar UI—reducing complexity while maintaining familiar scroll feel.

Library Comparison

react-window

Author: Brian Vaughn (bvaughn), former React team member

Design philosophy: Minimal, focused alternative to react-virtualized.

Components:

• FixedSizeList / VariableSizeList
• FixedSizeGrid / VariableSizeGrid

Bundle size: ~6KB gzipped

Best for: Teams wanting a lightweight, well-maintained React solution for common virtualization patterns.

react-virtuoso

Specialization: Variable-height content with automatic measurement.

Key features:

• ResizeObserver-based automatic height tracking
• Built-in handling for prepending items (chat use case)
• Grouped lists with sticky headers

Bundle size: ~15KB gzipped

Best for: Social feeds, chat interfaces—anywhere content heights vary unpredictably.

@tanstack/virtual

Author: Tanner Linsley (TanStack maintainer)

Architecture: Framework-agnostic core with adapters for React, Vue, Svelte, Solid.

Key innovation: Inversion of control—framework adapters implement browser interactions, core handles calculations.

Bundle size: ~10KB gzipped (core)

Best for: Multi-framework teams, or when you need virtualization outside React.

Library Decision Matrix

Conclusion

Virtualization is the only viable approach for rendering large lists in the browser. The core principle—render only what’s visible—transforms O(n) DOM operations into O(viewport) regardless of list size.

Choose your approach based on constraints:

• Fixed-height virtualization when you can enforce uniform item heights—simplest and fastest
• Variable-height virtualization for real-world content—the production standard
• DOM recycling when GC pauses are unacceptable—adds complexity but eliminates allocation churn
• CSS content-visibility when find-in-page matters and list size is under ~10K—simplest implementation, keeps full DOM

The implementation details matter: use transform over top, RAF-throttle scroll events, manage focus for accessibility, and handle the edge cases (scroll jumping, bidirectional scrolling, dynamic content) that differentiate production code from demos.

Appendix

Prerequisites

• Browser rendering pipeline (layout, paint, composite)
• React or framework fundamentals (for library examples)
• Basic understanding of time complexity notation

Terminology

Summary

• Virtualization keeps DOM size constant (O(viewport)) regardless of list length
• Fixed-height is simplest (pure math); variable-height handles real content
• Use transform: translateY() for GPU-accelerated positioning
• ResizeObserver measures heights; IntersectionObserver detects visibility
• content-visibility: auto is a CSS-only alternative that preserves find-in-page
• Focus management and ARIA attributes are critical for accessibility
• Real-world implementations (Discord, Figma, VS Code) combine techniques based on their specific constraints

References

• W3C Intersection Observer Specification - Authoritative API specification
• CSSWG ResizeObserver Specification - Observer API for element size changes
• MDN: content-visibility - CSS property documentation
• web.dev: Virtualize long lists with react-window - Chrome DevRel implementation guide
• web.dev: content-visibility: the new CSS property that boosts your rendering performance - Performance case study
• TanStack Virtual Documentation - Framework-agnostic library docs
• react-window GitHub - Library source and documentation
• react-virtuoso Documentation - Variable-height virtualization library
• WICG Virtual Scroller Proposal - Ongoing standardization effort
• Figma: Keeping Figma Fast - Canvas virtualization case study
• AG Grid: DOM Virtualization - Grid virtualization patterns