React performance optimization: what actually moves the needle

The biggest performance mistake I've made and watched other teams make is optimizing by intuition. Before touching a single component, I run the React DevTools Profiler and Chrome's Performance panel to find where time is actually going — not where it feels like it's going.

On a recent dashboard rewrite, the assumed bottleneck was a heavy chart component. The profiler showed the real cost was a context provider re-rendering 40 unrelated components on every WebSocket tick. Fixing the actual bottleneck took an hour; the chart component needed no changes at all.

Route-based code splitting is table stakes. The bigger win came from splitting inside routes: modals, settings panels, and admin-only views loaded via `React.lazy` so the initial bundle only includes what the first paint needs.

• Initial JS bundle dropped from 480KB to 210KB gzipped after splitting rarely-used panels
• Largest Contentful Paint improved by 1.2s on mid-tier mobile devices
• Prefetch on hover/focus for likely next routes, so the split doesn't cost a visible delay
• Measure with real device throttling — desktop dev machines hide most of the pain

`React.memo`, `useMemo`, and `useCallback` are not free. Wrapping every component and every function reference adds comparison overhead and cognitive load without preventing renders that were already cheap. I only add memoization where the Profiler shows a component both re-renders often and does non-trivial work per render.

The pattern that actually paid off: memoizing expensive derived data (filtered lists, computed aggregates) with `useMemo`, and memoizing components that render inside a virtualized list, where render count is naturally high.

Any list, table, or feed that can exceed roughly 50 rows gets windowed rendering. On a scheduling table with several thousand rows, virtualization took interaction latency from a stuttering 400ms-plus per scroll frame down to a consistently smooth frame budget.

This matters more than almost any other single change on data-heavy dashboards, because it bounds the DOM node count regardless of how much data the backend returns.

Lighthouse scores are a proxy, not the goal. I track Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift — from real user sessions via analytics, segmented by device and connection type, because lab scores on a fast laptop hide most of what real users experience.

The last optimization pass focused entirely on the P90 mobile experience instead of the median desktop one, since that's where the actual complaints were coming from — and that's where the fixes had the biggest measurable impact on conversion.