React Component Performance

React Component Performance

Overview

This skill preserves the intent of the upstream community workflow while making it more operational for real React performance investigations.

Use it to diagnose a slow React component or interaction, identify the dominant cause, and propose the smallest targeted fix that can be validated with measurement. The default posture is profile first, change one thing at a time, and re-measure.

Prefer structural fixes before blanket memoization:

• keep transient state local
• remove unnecessary Effects
• keep rendering pure
• simplify props passed into expensive children
• reduce DOM and list size when volume is the real bottleneck

Keep provenance visible if you are using this as part of an imported or reviewed upstream workflow.

When to Use This Skill

Use this skill when:

• a React component, interaction, or screen feels slow and the user wants targeted fixes
• you need to diagnose excessive re-renders, expensive renders, typing lag, or list/scroll lag
• the right answer depends on distinguishing React render work from browser layout/paint/network work
• you need a profiler-driven workflow instead of generic advice like “add memo everywhere”
• you must preserve the upstream workflow and provenance while improving the operator guidance

Do not use this skill as the primary workflow when:

• the issue is mainly server latency, API throughput, or network waterfalls
• the slowdown is clearly outside React, such as CSS/layout thrash, large paints, or long-running non-React scripts; in that case, escalate to browser performance tooling after confirming React is not the main bottleneck
• the request is about bundle size, code splitting, or asset delivery rather than component render behavior

Operating Table

Workflow

1. Confirm the symptom

   • Identify the slow interaction precisely: initial render, typing, click response, filtering, scrolling, tab switch, modal open, or route change.
   • Reproduce it in a production-like build when possible. Development mode behavior can exaggerate costs and mislead optimization decisions.

2. Profile before changing code

   • Open React DevTools Profiler.
   • Record only the slow interaction.
   • Review:
     • which components rendered
     • which components rendered repeatedly
     • which components had the highest self time or total time
     • whether props, state, or context caused the render
   • If React time is not the dominant cost, switch to the browser Performance panel.

3. Classify the bottleneck Use the profiler result to decide which class of problem you have:

   • render frequency: too many commits or too many components updating
   • render cost: one or a few components are individually expensive
   • effect churn: an interaction causes extra commits because Effects derive state or synchronize unnecessarily
   • list volume: too many rows are mounted or updated
   • interaction scheduling: urgent UI updates are blocked by non-urgent heavy work

4. Choose the smallest high-value fix Prefer these in roughly this order:

   • move state closer to where it is used
   • remove unnecessary Effects and derived state stored in state
   • simplify props flowing into expensive children
   • keep rendering pure and avoid work during render that can be avoided or cached
   • use memo only when the child is expensive and often receives the same props
   • use useMemo for expensive calculations or to preserve values passed to memoized children
   • use useCallback mainly when stable function identity matters
   • virtualize long lists when row count is the real problem
   • use startTransition or useDeferredValue when non-urgent updates should not block urgent interactions

5. Apply one change at a time

   • Avoid stacking several optimizations before re-measuring.
   • Record exactly what changed and why.
   • If using memoization, confirm that props are actually stable enough for it to work.

6. Re-profile and compare

   • Capture the same interaction again.
   • Compare render count, commit count, and expensive component times against the baseline.
   • Keep the change only if it reduces real cost or improves responsiveness.

7. Document tradeoffs and boundaries

   • Note what was measured.
   • Note the chosen fix and why alternatives were rejected.
   • Call out any library-specific or framework-specific assumptions.

Diagnostic Heuristics

Frequent re-renders

Common causes:

• state lifted too high
• parent component updating broad subtrees unnecessarily
• unstable object, array, or function props
• context updates affecting too much UI
• Effects that set state after render

Usually test next:

• colocate state
• split expensive children from fast-changing state
• pass simpler props
• stabilize values only where profiler evidence justifies it

Expensive individual render

Common causes:

• heavy derived calculations inside render
• large subtree generation
• repeated sorting/filtering/mapping for the same inputs
• expensive formatting or transformation repeated each render

Usually test next:

• move or cache expensive derived work with useMemo if it is measurably expensive
• reduce work done on every render
• isolate expensive children behind stable props and targeted memo