All articles
Engineering

React Performance Is a Design Problem

Piumal DhanawardhanaApril 3, 20257 min read

Every few months I join a project where the senior engineer is angry at React. memo everywhere, useCallback chained like prayer beads, and a profiler open for hours chasing a stall that never quite disappears. I’ve been that engineer. And almost every time, the real culprit wasn’t React - it was a design decision made before the first line of code.

The frame, not the component

Browsers paint in frames - 16.7ms each. If you think about your interface in terms of what has to happen inside a single frame, everything changes. A list re-render isn’t slow because React “re-renders things”; it’s slow because the DOM work you asked for can’t fit in one frame.

The best performance fix is usually to ask for less work, not to make the work faster.

Three design choices that wreck performance

1. Layouts with dozens of absolutely positioned layers. Every one of those layers participates in layout and paint. A design that stacks 40 absolutely-positioned cards on top of each other will fight the browser forever.

2. Animations that trigger layout. Animating top, margin, or width forces the browser to recompute layout each frame. Animating transform and opacity runs on the compositor. The difference is the difference between 60fps and a slideshow - and it’s decided in the mockup, not the code.

3. Data-fetch-on-mount waterfalls. When every component fetches independently as it mounts, the page loads in serial spikes. Designing a screen around a single, predictable data contract collapses that waterfall into one request.

Fixed in the design, not the profiler

I’ve stopped “fixing” these with memo and started asking the design team questions first: Does this card really need to be a separate layer? Can this animation move on the compositor? Can this whole section render from one data shape?

Nine times out of ten, the answer moves the performance needle more than a week in a profiler ever did.

Think in frames everywhere

Performance is not a code problem. It’s a constraint you design inside - exactly like color contrast or grid spacing. The moment the team treats it that way, the “React is slow” meetings stop happening.

React is fine. The designs we ask it to render are usually the problem.

- Get in touch

got an idea that needs
design and code?

Drawing ModeESC to clear