Advanced 18 min read

Handling Large Datasets and Pagination

By the end of this lesson, you'll be able to:

  • Explain why rendering very large lists is inherently slow
  • Apply pagination as the primary fix for large-dataset performance
  • Understand virtualization conceptually as a technique for extremely large lists

Prerequisites: "Efficient Wire Usage and Getter Performance"

Why Large Lists Are Slow

Rendering performance is driven largely by how many DOM nodes exist, not just how fast data arrives from the server. A list rendering 5,000 rows is genuinely slow to paint and interact with, even if all 5,000 records were fetched instantly — the bottleneck moves from the network to the browser's own rendering work.

Pagination as the Primary Fix

Module 10's pagination lesson exists for exactly this reason, not only to reduce server load — limiting how many rows are rendered at once (say, 50 per page) keeps the DOM node count, and therefore rendering cost, bounded regardless of how large the underlying dataset actually is.

Virtualization

For extremely large lists where even paginating feels limiting (a continuous scroll experience, for instance), virtualization is the more sophisticated technique: only the rows currently within — or just outside — the visible viewport are actually rendered as real DOM nodes; as the user scrolls, nodes are recycled and reused rather than the entire list existing in the DOM simultaneously. This is conceptually similar to pagination's core idea (bound the rendered row count) but applied continuously rather than in discrete pages.

Why This Matters in Real Projects

"It works with 20 test records but crawls with 5,000 real ones" is one of the most common real-world LWC performance complaints — and it is, more often than not, exactly this: too many DOM nodes rendered at once, with pagination (or virtualization, for genuinely extreme cases) as the fix.

Exercise

Explain, as a comment, why a list rendering 5,000 rows is slow even if all 5,000 records arrived from the server instantly.

Show hint

Think about where the actual bottleneck sits.

JAVASCRIPT

Exercise

Challenge: explain, as a comment, how virtualization differs from ordinary pagination while sharing the same core idea.

Show hint

Think about discrete pages versus continuous scrolling.

JAVASCRIPT

Handling Large Datasets and Pagination Quiz

1. What primarily drives rendering performance cost for a large list?

2. What does pagination bound in order to improve performance?

3. What does virtualization render, as the user scrolls?

4. Why might a component work fine with 20 test records but crawl with 5,000 real ones?

5. Is fetching data faster from the server a substitute for addressing DOM node count in a large list?

Log in to submit the quiz and save your score.

My Notes

Log in to keep private notes on this lesson.

Questions about this lesson

No questions yet — be the first to ask.

Log in to ask a question about this lesson.

Summary

DOM node count directly drives rendering cost — pagination limits how many rows exist at once, and virtualization takes that idea further by rendering only what's actually visible.