Design Long Lists With Virtualization
Performance & Reliability · performance, tables, loading
Updated 2026-07-28
- Render only what is near the viewport once a list gets long. Thousands of rows in the document will make scrolling stutter no matter how simple each row is.
- Keep the scrollbar honest. The track should represent the whole list, so the user can judge how much there is and drag to a rough position.
- Reserve the correct height for rows that have not rendered yet. Guessing wrong makes the scroll position jump as the user moves, which feels like the page fighting back.
- Handle rows of different heights explicitly. Variable content, wrapped text, and expandable rows all need measurement rather than a fixed estimate.
- Preserve the things users expect to survive scrolling:
- Selection, including select-all across the full set.
- Expanded and collapsed rows.
- In-progress edits.
- Scroll position when returning from a detail view.
- Keep the list findable. Virtualized rows are not in the document, so browser find, keyboard navigation, and screen reader counts all need explicit support.
- Give long lists an anchor. Sticky headers, a jump-to-letter control, or grouped sections stop the middle of a huge list from feeling like nowhere.
- Do not virtualize small lists. The complexity is only worth it past the point where rendering everything is measurably slow.
Virtualization is an implementation detail that users should never notice, and they notice it the moment it loses their place.
Related guides