A windowed list: 10,000 rows, about 15 in the DOM
Scroll it yourself: the scrollbar is the size of 10,000 rows, but only the visible rows plus 3 overscan rows on each side exist. At the top there's no overscan above row 1, so there are 12 rows; in the middle there are 15. (key={i} is fine here: the index is the row's identity in this fixed list.)
Rendering thousands of rows is slow because every row costs React work and DOM nodes the browser must lay out and paint; windowing (virtualisation) renders only the rows in view plus a few extra, libraries like TanStack Virtual and react-window do it for you, and CSS content-visibility is a lighter alternative for long pages.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
A product page renders 300 product cards in a long scrolling page and scrolling feels janky. Suggest a no-JavaScript improvement and show the CSS.
Given a fixed row height of 40px, a viewport of 400px and overscan 2, which rows render when scrollTop is 2,000?
Explain it without notes
Why is rendering 10,000 list rows slow? Name the different costs.
How does windowing work?
What are the downsides of virtualising a list?
When would you choose content-visibility: auto over a virtualisation library?
Preview
Console
Nothing logged yet.Expected console output
At the top: 12 rows in the DOM, Order #1 to Order #12
After scrolling: 15 rows in the DOM, Order #4998 to Order #5012