Virtualized Table — Windowed Row Rendering HTML CSS JS

Rendering five thousand <tr> elements into the DOM at once is slow to build, slow to lay out, and heavy on memory — most of those rows are never on screen at any given moment. Virtualization (also called windowing) fixes this by keeping only the rows that are actually visible, plus a small buffer, in the DOM at all times, while a spacer element fakes the full scrollable height so the scrollbar still behaves correctly. This snippet implements genuine windowed rendering over 5,000 generated rows in plain HTML, CSS, and vanilla JavaScript — no library, no shortcuts.

A full-height spacer, a tiny real table

The scroll container holds a .vrt-spacer sized to TOTAL_ROWS * ROW_HEIGHT pixels — the height the table *would* be if every row were rendered — so the browser's native scrollbar reflects the true scrollable distance. Inside it, the actual <table> is absolutely positioned and, at any moment, contains only a couple dozen <tr>s. The spacer is what makes the scrollbar honest while the DOM stays cheap.

Real scroll-position math, not a fixed slice

On every scroll event, renderWindow() reads scroller.scrollTop and converts that pixel offset into a row index with Math.floor((scrollTop - HEADER_HEIGHT) / ROW_HEIGHT) — genuine arithmetic tying the scroll position to which row is first visible, not a hardcoded window that never moves. visibleCount is derived from the viewport's actual clientHeight divided by the fixed row height, so the number of rows rendered adapts if the container is resized.

A buffer so fast scrolling doesn't flash blank rows

Rendering exactly the visible rows and nothing else would show a flicker of empty space during a fast scroll, since the new rows for the next frame haven't rendered yet. BUFFER pads startIndex and endIndex by a few extra rows on each side, so there's always a small overrun of already-rendered content beyond the viewport edge to scroll into before the next renderWindow() call catches up.

Absolute positioning to land rows at their true offset

Because only a slice of the data is ever in the DOM, the rendered <tbody> can't simply start at the top of the container — row 3,000 needs to visually sit 3,000 row-heights down. The <table>'s top style is set to startIndex * ROW_HEIGHT on every render, placing the small set of real rows at the exact pixel offset the full dataset would have put them, so scrolling feels seamless even though the underlying DOM content is constantly being swapped out.

Sticky header, live row count

The header stays position: sticky within the scroll container so column labels remain visible regardless of scroll position, and a live label reports exactly which row indices and how many actual DOM rows are rendered at any moment — useful for seeing the technique work, and a good sanity check that it never renders anywhere close to all 5,000 rows.

Customizing it

Swap fixed-height rows for variable heights (requires tracking cumulative offsets instead of a constant multiply), add horizontal virtualization for very wide tables, or combine with a frozen columns table for pinned columns on a huge dataset. Pair with an infinite scroll table if the data is paginated from a server instead of generated upfront.