Virtual data grid

A naive table mounts one DOM node per cell, so 100k rows × 8 columns is 800k+ nodes — layout alone blows past the 16ms frame budget and the tab stalls before the first paint. Windowing fixes this: a tall scroll spacer reserves total height (rowCount × rowHeight), an absolutely-positioned viewport renders only the slice the scrollTop intersects, and you recompute startIndex = floor(scrollTop / rowHeight) on each scroll. With a 600px viewport and 32px rows that's ~19 visible rows; add an overscan buffer of 4–8 rows above and below so a fast flick doesn't expose blank gaps before the next frame paints. The whole point is keeping the live node count near 30 instead of 800k, so each frame's style+layout+paint fits inside 16ms.

Real rows wrap text and grow, so the fixed-rowHeight math breaks: floor(scrollTop / rowHeight) no longer points at the right row, and total height is a guess. You need a measurement cache — measure each row's real height once (after it mounts, via ResizeObserver or offsetHeight), store it, and use an estimated height for rows you haven't seen yet. Map scrollTop → startIndex with a prefix-sum/binary search instead of division; a Fenwick (binary-indexed) tree gives O(log n) offset queries and O(log n) updates when one row remeasures, versus O(n) for a flat prefix array rebuilt on every change. The tradeoff: estimates make the scrollbar 'breathe' as real heights land, so anchor the visible row on remeasure to avoid scroll jumps, and cap the cache (100k entries × a few bytes is fine; don't also retain detached DOM).

A wide grid (say 60 columns) hits the same node explosion horizontally: 30 visible rows × 60 columns is 1,800 cells, but only ~12 columns are on screen. Virtualize the X axis the same way — track scrollLeft, compute the visible column window, and offset each cell by its column's cumulative left. Frozen (pinned) columns are the hard part: the first one or two columns must stay put while the rest scroll, so they live in a sticky layer with a higher z-index and the scrolling body's left padding accounts for their width. The tradeoff is composability — frozen + horizontal virtualization means two coordinate systems (pinned vs scrolling) that must agree on row height and selection, and a wrong z-index or transform makes pinned cells bleed under the body during a fast scroll.

100k rows in the browser is fine for a demo; in production the data lives on a server and you can't ship it all. Switch to windowed fetching: as the visible window moves, request the slice you need (offset/limit or, better, keyset/cursor pagination so deep pages don't degrade), keep a page cache keyed by range, and render skeleton rows for ranges in flight so scrolling never blocks on the network. Push sort and filter to the server — sorting 100k rows client-side is an O(n log n) main-thread stall, and the server can ride an index — which means a sort/filter change invalidates your cached pages and resets the window. The tradeoff is latency vs. correctness: prefetch the next window to hide round-trips, but debounce filter input and cancel stale requests so a fast typer doesn't render results from an abandoned query.

A virtualized grid is hostile to screen readers and keyboards by default: rows that aren't in the DOM don't exist to assistive tech, and focus vanishes when the focused cell scrolls out and unmounts. Build the real ARIA grid pattern — role="grid" / "row" / "gridcell", aria-rowcount/aria-colcount set to the full 100k (not the rendered slice), and aria-rowindex on each rendered row so a reader announces "row 90,000 of 100,000". Implement roving tabindex: exactly one cell is tabbable, arrow keys / Page Up-Down / Home-End move focus, and when the focused cell scrolls out you must restore focus to its element when it remounts (track focus by row/col index, not by DOM node). Layer range/multi-row selection (Shift+click, Shift+Arrow, Ctrl/Cmd toggle) and inline cell editing (Enter to edit, Escape to cancel, commit on blur) on top. The tradeoff senior engineers miss: virtualization and accessibility fight each other, and the fix is making focus and selection live in data state, with the DOM as a disposable projection of it.

Now make it provably fast and then break it on purpose. Set a budget: initial mount of 100k rows under 200ms, steady 60fps (≤16ms frames) during a sustained scroll, and INP under 200ms for cell focus/edit interactions. Profile in Chrome Performance — a flamechart of a scroll should show no long tasks (>50ms); the usual culprits are synchronous layout reads inside the scroll handler (layout thrash), per-frame allocations feeding GC pauses, and unbatched state updates. Fix scroll handling by reading scroll state and writing DOM in the right phase (requestAnimationFrame, not on every scroll event), and batch the window recompute. Then the incident: a teammate's 'harmless' change — adding a getBoundingClientRect() read inside the row render, or dropping the rAF batch — reintroduces a scroll-stutter regression that only shows under sustained fast scroll on 100k rows. Reproduce it, catch it in a profile (forced reflow / long task), localize the offending span, fix it, and write a short regression note so it can't silently come back.