Web Performance: Reduce Re-Renders

SPAs aim to deliver a smooth, app-like experience. As features grow, code can bloat and performance bottlenecks appear—time for optimization. One lever is reducing render frequency.

Using React as the example (Angular/Vue are similar):

All frameworks re-render DOM from component state. Components partition the UI, so updates are localized. Misuse can cause duplicate/unnecessary renders. The goal: render only what needs rendering, when it needs rendering.

React Strategies

React class components offer shouldComponentUpdate. By default, changes in props/state trigger re-render. Also, when a parent renders, children render too—even if their props didn’t change.

Since React 15.3+, PureComponent implements shouldComponentUpdate with shallow comparison; if nothing changed, it skips render. For function components (React 16.6+), React.memo provides the same benefit.

Can we just switch everything to PureComponent/memo? No.

Shallow compares work best with primitives. With object references, equal-by-value changes may still trigger renders. Choose the right approach per prop type. Ultimately, control render frequency with shouldComponentUpdate or custom comparators passed to memo.

Example

In a recent optimization, the footer rendered 7 times. It depended on many Redux objects. PureComponent didn’t help because props were complex objects. Business-specific checks on actual values reduced renders to 2—and correct. From 7 to 2 is a big win.

For complex interactive pages, the outer components suffer most: redundant renders cascade into nested trees—costly.

Redux Pitfalls

In many React stacks, components connect to Redux. A common mistake is connecting overly large objects (e.g., person) when the component only needs person.name. Any change in person triggers renders even if the used field didn’t change. Connect at the right granularity and level.

Final Thoughts

DOM operations are expensive. Reducing frequency is a key frontend goal.