Advanced 15 min read

Component Composition for Performance

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

  • Split a large component to isolate frequent re-renders to a smaller child
  • Recognize the real overhead that comes with excessive component nesting
  • Apply a balanced approach to component decomposition

Prerequisites: "Handling Large Datasets and Pagination"

Splitting Components to Isolate Re-Renders

If one small piece of a UI updates frequently — a live counter, a countdown timer — and it's embedded directly inside a large parent component's own template, the entire parent's template re-evaluates every time that piece changes, even though the rest of the parent's content didn't actually change. Extracting the frequently-changing piece into its own small child component confines that re-render cost to just the child, leaving the rest of the parent's larger template untouched.

The Cost of Excessive Nesting

Component boundaries aren't free — each one carries its own lifecycle hooks (Module 11), its own reactivity tracking, and its own rendering pass. Splitting a UI into far more components than genuinely necessary, purely on principle, can add more overhead than it saves. Decomposition for performance is a deliberate trade-off, not an unconditional "more components is always better" rule.

A Balanced Approach

Split out a child component when a genuinely isolated, frequently-changing piece of UI can be cleanly separated from a larger, more stable parent. Don't split reflexively for every small piece of markup — the goal is isolating real, measured re-render cost, not maximizing component count for its own sake.

Exercise

A dashboard component has a large, mostly-static account summary and a small "last updated X seconds ago" timestamp that changes every second. Explain, as a comment, how splitting this would help performance.

Show hint

Think about what re-renders every second without splitting.

JAVASCRIPT

Exercise

Challenge: explain, as a comment, why splitting every single small piece of markup into its own component is not automatically a performance win.

Show hint

Think about what each new component boundary itself costs.

JAVASCRIPT

Component Composition for Performance Quiz

1. What happens to a large parent's entire template when a small embedded piece changes frequently?

2. What does extracting a frequently-changing piece into its own child component achieve?

3. Do component boundaries carry real overhead of their own?

4. Is splitting a UI into as many small components as possible always a performance win?

5. What should guide the decision to split out a child component for performance reasons?

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

Splitting components can isolate expensive re-renders to a small part of the UI — but component boundaries have their own real overhead, so decomposition for performance is a balance, not an unconditional good.