Technologies
React Performance Optimization
React performance problems are almost always one of two things: components re-rendering more than they need to, or too much JavaScript being downloaded and parsed before the app becomes interactive. Both are fixable once you can see exactly what's happening, which is why profiling comes before any optimization work.
I use React's built-in Profiler and browser dev tools to find the actual bottleneck before reaching for memoization or code-splitting — guessing at performance fixes tends to add complexity without fixing the real problem.
Common Causes of Slowness
- arrow_rightPassing new object or function references as props on every render, defeating memoization
- arrow_rightExpensive computations running on every render instead of being memoized
- arrow_rightLarge lists rendered without virtualization
- arrow_rightContext providers causing every consumer to re-render on any state change, even unrelated ones
- arrow_rightOversized dependencies bundled into the initial load instead of code-split
Fixes, In Order of What I'd Try First
- Profile first — find which components are re-rendering and why, using React DevTools Profiler
- Fix unnecessary re-renders at the source (state placement, prop stability) before reaching for memo/useMemo
- Virtualize long lists so only visible items render
- Code-split routes and heavy components so the initial bundle stays small
- Split large context providers so unrelated state changes don't cascade re-renders
Frequently Asked Questions
Should I wrap everything in React.memo?add
No — memoization has its own cost (comparing props on every render) and adds complexity. It's worth applying to components that render often with the same props and are expensive to re-render, not as a blanket default.
What's the biggest performance mistake you see?add
State placed too high in the component tree, so a small UI change triggers a re-render of a much larger subtree than necessary. Moving state closer to where it's actually used fixes more performance problems than any memoization technique.
Does TypeScript affect runtime performance?add
No — TypeScript is compiled away entirely before the code runs; type checking happens at build time and has zero runtime cost.