Architecting Virtualized Data Grids: 100k Rows, Dynamic Heights, and DOM Recycling

In enterprise web software—analytics dashboards, financial trading terminals, cloud observability tools, and database viewers—users expect to scroll through datasets containing 10,000 to 1,000,000 records effortlessly. Yet asking a modern web browser to mount 100,000 table rows into the Document Object Model (DOM) results in catastrophic performance collapse: memory consumption explodes beyond 2 gigabytes, style recalculations freeze the main thread for seconds, and user scrolling stutters at unplayable frame rates.

The solution is DOM Virtualization (often called windowing). Instead of instantiating thousands of HTML nodes, a virtualized grid renders only the minute slice of elements currently visible within the viewport—typically 20 to 30 elements—alongside a small overscan buffer. As the user scrolls, the engine recalculates boundaries, updates data references, and translates existing DOM nodes using hardware-accelerated GPU transforms.

While fixed-height virtualization is relatively straightforward, production requirements introduce intense complexity: variable-height text, collapsible JSON inspectors, dynamic badge wraps, and upward scrolling with anchor stability. In this systems guide, we will design and construct an enterprise-grade virtualized data grid engine capable of rendering 100,000 dynamic rows at a locked 60 frames per second with sub-millisecond Interaction to Next Paint (INP).

1. The Physics of Browser Rendering Breakdown

To understand why virtualization is mandatory, we must examine what occurs inside Blink and Gecko rendering engines when an application renders a massive table:

1. DOM Node Memory Overhead: A single table row with 8 cells containing styled text, status badges, and event listeners is not just a few bytes of HTML. Each DOM element represents a C++ Element class instance in the browser engine, paired with V8 JavaScript wrapper objects, CSS computed style maps, and layout tree fragments. 100,000 rows ($800,000$ cells) routinely consume 800 MB to 1.8 GB of heap memory.
2. Recalculate Style & Reflow Thrashing: Whenever a style changes (or an animation triggers), the browser executes CSS selector matching and layout geometry calculations. The time complexity of layout is proportional to the depth and count of nodes in the DOM tree ($O(N)$). With 800k nodes, a single class toggle triggers a 300ms–800ms main thread stall, destroying Core Web Vitals (specifically INP).
3. Paint & Composite Bandwidth: The browser must rasterize visible pixels. Even with off-screen layer clipping, managing massive layout trees forces continuous garbage collection cycles that cause frame drops and scroll hitching.

By enforcing virtualization, we bound the DOM footprint to a constant $O(\text{viewport})$: whether the underlying dataset contains 500 items or 5,000,000 items, the active DOM contains exactly 25 to 35 nodes, consuming less than 150 KB of memory.

2. Fixed vs. Variable Height Virtualization

In a simplified fixed-height table where every row is guaranteed to be exactly $40\text{px}$, calculating the visible window requires trivial arithmetic:

// Fixed-Height Window Calculation: O(1)
const startIndex = Math.floor(scrollTop / rowHeight);
const endIndex = Math.min(totalCount - 1, Math.ceil((scrollTop + viewportHeight) / rowHeight));
const offsetY = startIndex * rowHeight;

However, enterprise data rarely adheres to rigid heights. User comments wrap onto multiple lines, localized strings fluctuate in width, nested detail panels expand, and code snippets render variable blocks. In dynamic environments, fixed multiplication fails: the engine must know the exact cumulative height of every item to calculate viewport intersections and maintain an accurate scrollbar.

3. Prefix-Sum Array Offset Indexing & Binary Search

To support variable heights without iterating through 100,000 items on every scroll tick ($O(N)$), we maintain a Prefix-Sum Cumulative Offset Array:

$$\text{offsets}[i] = \sum_{k=0}^{i-1} H_k, \quad \text{where } \text{offsets}[0] = 0$$

Because every height $H_k > 0$, the offsets array is strictly monotonically increasing. This mathematical property allows us to use Binary Search to determine the first visible row in $O(\log N)$ time.

For a table with 100,000 rows, a linear scan requires up to 100,000 operations per frame. A binary search resolves the exact index in at most **17 iterations** ($\lceil \log_2(100,000) \rceil = 17$), executing in approximately 0.02 milliseconds:

/**
 * Locates the lowest index whose cumulative offset is >= target scrollTop
 * Time Complexity: O(log N)
 */
export function findStartIndex(offsets: Float64Array, scrollTop: number): number {
  let low = 0;
  let high = offsets.length - 1;
  let result = 0;

  while (low <= high) {
    const mid = (low + high) >>> 1;
    if (offsets[mid] >= scrollTop) {
      result = mid;
      high = mid - 1; // Narrow search to the left
    } else {
      low = mid + 1;  // Search to the right
    }
  }

  return Math.max(0, result - 1);
}

4. Dynamic Measurement via ResizeObserver & Anchor Stability

When items first load, their exact rendered height is unknown. We initialize unmeasured rows with an estimated default height (e.g. $45\text{px}$). As rows enter the viewport, a shared ResizeObserver measures their true bounding box and updates the index cache.

Eliminating the Dreaded "Scroll Jitter" (Upward Scroll Drift)

A classic failure in naive virtualization occurs when scrolling upwards. If an unmeasured row above the viewport is estimated at $40\text{px}$, but its true rendered height is $85\text{px}$, measuring it increases total content height by $45\text{px}$. If the container's scrollTop remains unchanged, the content underneath instantly shifts down by $45\text{px}$, causing severe visual jumping.

To eliminate scroll jitter, whenever an item above the current viewport changes height by $\Delta H$, we immediately compensate the scroll container:

$$\text{scrollTop}_{\text{new}} = \text{scrollTop}_{\text{current}} + \Delta H$$

By executing this adjustment synchronously before the browser paints, the visible items remain locked in place with zero visual stutter.

export class SizeCache {
  private heights: Float64Array;
  private offsets: Float64Array;
  private isMeasured: Uint8Array;
  private defaultHeight: number;

  constructor(totalCount: number, defaultHeight = 45) {
    this.defaultHeight = defaultHeight;
    this.heights = new Float64Array(totalCount).fill(defaultHeight);
    this.offsets = new Float64Array(totalCount);
    this.isMeasured = new Uint8Array(totalCount);
    this.recomputeOffsets(0);
  }

  public updateHeight(index: number, measuredHeight: number): number {
    if (this.isMeasured[index] && Math.abs(this.heights[index] - measuredHeight) < 0.5) {
      return 0; // Height unchanged
    }

    const delta = measuredHeight - this.heights[index];
    this.heights[index] = measuredHeight;
    this.isMeasured[index] = 1;
    this.recomputeOffsets(index);
    return delta;
  }

  private recomputeOffsets(fromIndex: number): void {
    const start = Math.max(0, fromIndex);
    let cumulative = start === 0 ? 0 : this.offsets[start - 1] + this.heights[start - 1];

    for (let i = start; i < this.offsets.length; i++) {
      this.offsets[i] = cumulative;
      cumulative += this.heights[i];
    }
  }

  public getTotalHeight(): number {
    const last = this.offsets.length - 1;
    return last >= 0 ? this.offsets[last] + this.heights[last] : 0;
  }

  public getOffset(index: number): number {
    return this.offsets[index];
  }
}

5. DOM Recycling & GPU Layer Compositing

Many virtual table implementations unmount old components and mount new ones on every scroll tick. Unmounting and mounting component instances incurs massive garbage collection churn and virtual DOM diffing overhead.

In our architecture, we maintain a fixed pool of DOM node containers. When an element scrolls out of view:

1. We update its internal text content or data binding references.
2. We position the container using CSS transforms rather than altering top:

   .virtual-row {
     position: absolute;
     top: 0;
     left: 0;
     width: 100%;
     will-change: transform;
     transform: translateY(var(--offset-y)) translateZ(0);
   }
   

Altering top forces the browser to re-execute layout geometry. Conversely, transform: translateY() operates strictly in the browser's compositing thread on the GPU, completely bypassing layout and paint cycles and delivering rock-solid 60 FPS scrolling.

6. Complete TypeScript Implementation

Below is the complete, dependency-free core engine implementing the windowing lifecycle:

export interface VirtualOptions {
  totalCount: number;
  viewportHeight: number;
  defaultRowHeight: number;
  overscan?: number;
}

export interface VirtualWindow {
  startIndex: number;
  endIndex: number;
  renderStartIndex: number;
  renderEndIndex: number;
  offsetY: number;
  totalHeight: number;
}

export class VirtualGridEngine {
  private sizeCache: SizeCache;
  private totalCount: number;
  private viewportHeight: number;
  private overscan: number;

  constructor(options: VirtualOptions) {
    this.totalCount = options.totalCount;
    this.viewportHeight = options.viewportHeight;
    this.overscan = options.overscan ?? 5;
    this.sizeCache = new SizeCache(options.totalCount, options.defaultRowHeight);
  }

  public compute(scrollTop: number): VirtualWindow {
    const totalHeight = this.sizeCache.getTotalHeight();
    const clampedScrollTop = Math.max(0, Math.min(scrollTop, totalHeight - this.viewportHeight));

    // 1. Binary search visible bounds
    const startIndex = this.findRowAtOffset(clampedScrollTop);
    const endIndex = this.findRowAtOffset(clampedScrollTop + this.viewportHeight);

    // 2. Add overscan buffer
    const renderStartIndex = Math.max(0, startIndex - this.overscan);
    const renderEndIndex = Math.min(this.totalCount - 1, endIndex + this.overscan);

    // 3. Compute GPU translation offset for the first rendered row
    const offsetY = this.sizeCache.getOffset(renderStartIndex);

    return {
      startIndex,
      endIndex,
      renderStartIndex,
      renderEndIndex,
      offsetY,
      totalHeight,
    };
  }

  public recordMeasurement(index: number, height: number): number {
    return this.sizeCache.updateHeight(index, height);
  }

  private findRowAtOffset(targetY: number): number {
    return findStartIndex(this.sizeCache.getOffsetsArray(), targetY);
  }
}

7. Keyboard Accessibility & Screen Reader Support

A common pitfall of virtualized data grids is breaking screen readers and keyboard navigation. Because unrendered rows do not exist in the DOM, pressing Tab or Down Arrow causes focus to drop off into empty space.

To adhere to WCAG 2.1 AA and WAI-ARIA grid standards, implement the following attributes:

• role="grid" on the container element, with aria-rowcount="100000" representing the full virtual dataset size.
• role="row" on rendered items, with aria-rowindex="2481" indicating the absolute record index.
• Roving Tabindex: Maintain active focus on a single coordinate (row, col) using tabindex="0" while setting all other rendered cells to tabindex="-1".
• Keyboard Event Interception: When the user presses Arrow Down at the bottom of the rendered viewport, the engine programmatically advances the virtual window and focuses the newly mounted row before the browser processes default focus routing.

8. Performance Benchmarks