Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Use when reviewing dashboards, admin tables, search results, or feeds with many repeated items. Confirm the bottleneck is DOM or rendering cost before introducing virtualization because small lists usually do not need the added complexity.
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-02 | ✗→✓ | ▲ Improved | 13% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 17% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 5% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 6% | 0% |
| case-13 | ✗→✓ | ▲ Improved | 12% | 0% |
Rendering hundreds or thousands of rows at once wastes memory and makes style calculation, layout, and painting more expensive. Virtualization keeps large collections responsive by limiting the number of mounted nodes.
Inspect long lists, tables, grids, and feeds for places where the UI renders every item at once. Flag views where the number of mounted rows or cards is large enough to create DOM, memory, or scroll-performance issues.
Introduce list or table virtualization so only the visible rows plus overscan render, while preserving sizing, keyboard navigation, and any required sticky headers or selection behavior.
Explain list virtualization, why it improves performance for large collections, and the tradeoffs engineers need to watch for around measurement and accessibility.
Inspect collection components, data tables, infinite feeds, and dashboards. Flag places where rendering the full dataset creates excessive DOM nodes or scroll jank, and verify the virtualization strategy still preserves item identity, semantics, and expected interactions.
For full implementation details, code examples, and framework-specific guidance, see references/rule.md.
Rule page: https://frontendchecklist.io/en/rules/performance/list-virtualization
Other measured skills in the registry, with their headline benchmark lift.