A React team proposes virtualizing every long list in the product. As the reviewer, how do you decide which lists genuinely warrant windowing, and what would you push back on?

## Start with the number nobody has The first question is not technical: *how long are these lists in production, really?* Teams virtualize based on the worst case they can imagine rather than the distribution they actually serve. Instrument it — sample the rendered row count — and look at p50, p95 and p99. A list whose p95 is 60 rows and whose p99 is 4,000 has a tail problem, not a list problem, and a cap plus a filter may serve better than windowing every instance. ## The cost model has two factors, not one Render cost is roughly *rows times cost-per-row*. Windowing attacks the first factor only. That yields a simple triage: - **Many rows, cheap rows** (a plain text log, an id list): the classic virtualization case. Thousands of rows, a handful of nodes each. Windowing turns an unusable page into a fast one. - **Few rows, expensive rows** (200 cards, each with a chart, an avatar and three tooltips): windowing helps far less than it looks, because 20 expensive rows is still expensive. Fix the row instead — fewer nodes, no per-row observers, defer secondary content. - **Many rows, expensive rows**: do both, and do the row work first, since it also improves the virtualized case. - **Few rows, cheap rows**: do nothing. This is where a blanket policy does real damage. A useful proxy is total DOM nodes rather than row count. Three hundred rows at forty nodes each is 12,000 nodes; three thousand rows at four nodes each is the same. The browser cares about the product of the two. ## The alternatives that are cheaper to own Before virtualizing, ask whether the list should be that long at all: - **Server-side pagination or cursor-based loading** solves the payload as well as the DOM, and keeps every browser feature intact. - **Filtering and search-first interfaces** make long lists rare instead of fast. A user scrolling 10,000 rows to find one record is a design failure that windowing makes tolerable rather than fixes. - **A hard cap with a clear message** — showing the first 500 of 12,400, refine your filters — is honest, trivial to build, and often what users actually want. - **Cheaper rows.** Flattening markup and deleting per-row wrappers frequently buys more than windowing would, with no ongoing cost. - **Collapsed detail.** Clamping rows to a fixed height and moving overflow into an expandable panel keeps rows uniform, which also makes any future virtualization dramatically simpler. ## The recurring costs to name out loud Virtualization is not a one-time change; it is a constraint every subsequent feature must respect: - Browser features that walk the DOM — find-in-page, print, select-all — degrade permanently, and accessibility needs deliberate work such as declared counts and managed focus. - Sticky group headers, expandable rows, inline editing, drag-and-drop reordering and row animations all get harder, because rows mount and unmount underneath them. - Variable heights bring measurement, invalidation and scroll-anchoring bugs that recur whenever content shapes change. - Tests get harder: assertions about a row outside the window fail, so suites need scroll helpers or data-level assertions. - Nested virtualization — a windowed list inside windowed rows — is a strong smell; two scroll containers and two measurement caches interacting rarely pays off. ## What I would ask for in review 1. A profile: a recorded scroll with dropped frames, commit durations, and the total DOM node count for the worst real page. 2. The production row-count distribution, not a hypothetical. 3. What was tried on the row itself first. 4. For each proposed list, the interactions it must keep supporting — keyboard, selection, print, deep link — and who is doing that work. 5. A single shared, reviewed list component if we adopt it, so measurement, ARIA and focus handling are implemented once rather than nine times with nine sets of bugs. ## The framing that lands Virtualization is one of the few frontend optimizations that changes what the page *is*, not merely how fast it is. That makes it a product and accessibility decision as much as a performance one. "Every long list" is a policy; the right answer is a threshold backed by measurement, a shared implementation, and a documented list of what a virtualized list must ship with.