Virtualization Strategies
Reduce rendering overhead for long lists, feeds, and comment timelines.
Pattern level: meso
TL;DR
Render only what the viewport needs, while preserving navigation and measurement stability.
Decision criteria
- Fixed height lists are easiest and fastest.
- Variable heights need measurement caches and correction.
Trade-offs
Trade-off Matrix
Add trade-off rows in this section to compare options.
Testing + Accessibility Rubric
| Category | Level | Requirement | Done When |
|---|---|---|---|
| functional | unit | State transitions handle loading, success, empty, and error. | Reducer/state machine tests cover all transitions. |
| functional | integration | Client correctly maps API contracts into UI-ready view models. | Contract fixtures pass with no runtime shape mismatch. |
| a11y | integration | Full keyboard flow works for primary interaction loop. | Tab/Shift+Tab/Enter/Escape scenarios pass for critical controls. |
| a11y | e2e | Dynamic updates expose meaningful live region announcements. | Manual SR checks validate announcement timing and text quality. |
title: Virtualization Strategies summary: Compare fixed-size and dynamic-size virtualization for large lists. kind: pattern level: meso tags:
- performance
- testing
- a11y usedIn:
- slug: feed-list title: Feed List reason: Supports long, personalized feeds with stable FPS. comparePages:
- fixed-vs-variable-virtualization testingRubricId: dynamic-list-core
TL;DR
Use fixed-size virtualization when row heights are predictable; use dynamic-size only when content variability is required and measured.
Problem this solves
- Prevents render and memory cost from scaling linearly with list size.
- Keeps interaction latency predictable on mid-tier devices.
Decision criteria
- Prefer fixed-size rows for fastest scroll math and simpler caching.
- Prefer dynamic-size rows when content variability is unavoidable.
- Avoid virtualization when item counts are low and SEO/static rendering dominates.
Layered depth
Intro
Render only visible rows plus overscan while preserving a stable scroll anchor.
Decision criteria
Balance CPU cost, memory pressure, and implementation complexity against list size volatility.
Implementation detail
- Keep keys stable across pagination pages.
- Use anchored re-measure strategy for dynamic heights.
- Tune overscan separately for touch and desktop profiles.
Failure modes
- Re-measure storms trigger frame drops after image load.
- Key instability causes list jump and lost focus.
- Overscan too low causes blank gaps during fast flings.
Pitfalls
- Coupling virtualization state to network pagination state.
- Ignoring keyboard traversal and focus restoration after window changes.
Testing + accessibility rubric
Testing + Accessibility Rubric
| Category | Level | Requirement | Done When |
|---|---|---|---|
| functional | unit | State transitions handle loading, success, empty, and error. | Reducer/state machine tests cover all transitions. |
| functional | integration | Client correctly maps API contracts into UI-ready view models. | Contract fixtures pass with no runtime shape mismatch. |
| a11y | integration | Full keyboard flow works for primary interaction loop. | Tab/Shift+Tab/Enter/Escape scenarios pass for critical controls. |
| a11y | e2e | Dynamic updates expose meaningful live region announcements. | Manual SR checks validate announcement timing and text quality. |
Production trade-offs
- Dynamic-size virtualization improves fidelity but increases implementation and test complexity.
- Higher overscan smooths scroll but raises memory and CPU usage.