Virtual Scroll HTML CSS JS — 10000 Item List

Rendering a list of ten thousand rows the naive way creates ten thousand DOM nodes, which janks scrolling, balloons memory and slows every layout. Virtual scrolling solves this by rendering only the handful of rows actually visible in the viewport while making the scrollbar behave as if the whole list were present. This component demonstrates the technique in plain JavaScript — no framework, no library — and adds live search and sort on top. Here is exactly how it works.

The core idea: a tall spacer plus a few real rows

A virtual list has three structural pieces. An outer viewport element has a fixed height and overflow-y: auto, giving it a scrollbar. Inside it sits a spacer whose height equals the total content height — items.length * ITEM_HEIGHT — so the scrollbar's range and thumb size are correct as if every row existed. Layered over the spacer is a small pool of actual row elements that get repositioned and refilled as you scroll. The user scrolls a giant invisible column but only ever sees a dozen or so real DOM nodes.

The single most important constant is ITEM_HEIGHT, the fixed pixel height of every row. A uniform height is what makes the math trivial: any row's vertical position is just its index times this height, and any scroll offset maps directly back to an index.

Computing the visible window

On each scroll, the handler reads viewport.scrollTop and derives which rows to render:

startIndex = Math.floor(scrollTop / ITEM_HEIGHT) visibleCount = Math.ceil(viewport.clientHeight / ITEM_HEIGHT) endIndex = startIndex + visibleCount + BUFFER

startIndex is simply how many full rows have scrolled past the top. visibleCount is how many rows fit in the viewport. BUFFER is a few extra rows rendered above and below the visible range so fast scrolling does not flash blank gaps before the next render catches up. The render loop then iterates only from startIndex to endIndex, a constant-size slice regardless of whether the dataset has a thousand or a million entries.

Positioning rows absolutely

Each rendered row is given position: absolute with top = index * ITEM_HEIGHT inside the spacer. This places every row at its true position in the full list even though only a window of them exists in the DOM. As you scroll, the same pool of row elements is recycled — their content and top values are rewritten to represent different indices — so the node count stays flat. The visual result is indistinguishable from a fully rendered list: smooth scrolling, a correctly sized scrollbar and rows appearing exactly where they should.

Throttling the scroll handler

Scroll events fire rapidly, often many times per frame. To avoid doing redundant work, the render is throttled with requestAnimationFrame: the scroll handler sets a pending flag and schedules a single render on the next animation frame, coalescing a burst of scroll events into one DOM update per frame. This keeps the main thread free and the list buttery even during flings.

Search filtering

Search recomputes a filtered array from the source data based on the query, then resets the virtual list to operate over that filtered array. Crucially, the spacer height is recalculated as filtered.length * ITEM_HEIGHT so the scrollbar shrinks to match the result count, and the visible window is re-derived from the new scrollTop. Because the index math only depends on the array length and item height, searching ten thousand items and re-rendering is instant — only the visible slice is ever touched in the DOM.

Sorting

A sort toggle reorders the underlying (or filtered) array by a field such as name. After sorting, the spacer height is unchanged but the row contents at each index differ, so a single re-render repaints the visible window in the new order. Sorting a huge list stays cheap for the same reason: the sort runs on plain data, and only the visible rows are rebuilt.

Generating the dataset

To exercise the technique, the demo generates ten thousand records programmatically, each with a name, role, status and a colored avatar initial. This synthetic data shows that the approach is bound by the number of *visible* rows, not the total. A counter typically displays how many DOM nodes are actually present — usually a dozen or two — versus the ten thousand a naive list would create, making the performance win concrete.

Why it matters

Virtual scrolling is the standard technique behind every high-performance list and table on the web — chat histories, data grids, file explorers, infinite feeds. The essentials are always the same: a fixed item height, a spacer sized to the full content, index math mapping scroll offset to a visible window, a small render buffer, absolute positioning by index, and rAF-throttled updates. This component distills all of that into a self-contained, dependency-free example you can adapt to any large dataset.