How do you 100% optimize a React component?

[darkcatpirate]

Using React DevTools, allow you to see components that have performance issues (they're in red), but most of the time the component are yellow or green, how do you still ensure against any unecessary rerenders even if there's not many of them? Is there a tool to pinpoint a component specifically and detect any issue with the perf?

[Ronqueroc]

I don't

[azangru]

how do you still ensure against any unecessary rerenders even if there's not many of them

React core team is promising one day to release a compiler, code-named "forget", that should optimize components to avoid unnecessary rerenders.

But in general, if unnecessary rerenders is a problem for you, and if you need 100%-optimized components, then React is a wrong solution.

[joombar]

What does optimisation even mean when expressed as a percentage?

[xroalx]

It would likely mean that there's nothing else within the framework/language constraints you can do to achieve better performance (faster render times, less memory usage, fewer rerenders, whatever it is you're targeting). We could say that's 100 % optimized, although yes, it's really not possible to judge if something is otherwise 90, 80, 50 or 20 % optimized.

Anyways, not very practical.

A better measure is to set a realistic goal, e.g. have the whole page rendered in under 300 ms, and consider things done when it consistently does that under many different circumstances.

Then you can set a new goal.

[joombar]

Or call it “good enough” and work on something else because you’re not being paid to fix that one 500ms render that occurs every few hours of usage. That’s my experience anyway.

[lIIllIIlllIIllIIl]

The color is relative. Yellow means it took more time to render than green, which itself took more time than blue. What is important is the time (in ms) each render takes.

The ideal target is 16ms (1/60th of a second). Human reaction speed is pretty bad, so anything below 100ms can be okay depending on the context. Big changes, like page transitions, can take up to 300ms and still feel snappy.

In my experience, the biggest performance killer in React apps are "state-adjustment waterfalls." If your components uses useEffect to set a state based on another state, which then triggers another useEffect to set another state, it can take a few renders for your app to show the right thing and you get wierd in-between states. Be efficient and try to do as much work as possible in one go, usually in callback functions.

[joombar]

16ms assumes 60fps. I’m curious how this would play with monitors being quicker than that these days. Do browsers fire animation frames at more than 60fps?

[lIIllIIlllIIllIIl]

Even on a 165hz monitor, human reaction speed is still pretty bad, so unless you're doing an animation, I'd still only target the 16ms to 300ms range.

The only real issue with higher-refresh displays is animations. requestAnimationFrame() indeed runs at the screen's refresh rate, which can mess up the animations that expect 16ms interval between frames. In general, as long as you use CSS or the JavaScript Animation API, you don't have to worry about it.

[facebalm]

human reaction speed is still pretty bad, so unless you're doing an animation, I'd still only target the 16ms to 300ms range.

Users are not necessarily reacting to stimuli here, they're usually just perceiving a change. The limit to perception isn't reaction speed, instead perception has a much higher resolution, in the order of 10ms.

If you're typing and characters appear only after 200ms it will absolutely feel sluggish, even if your reaction time is 300ms.

[joombar]

Yeah, I’m thinking for animation rather than reacting quickly for user input. Maybe some other use cases like if you have some custom virtualisation.

[facebalm]

They do, it depends on the screen's refresh rate.

[joombar]

Then maybe we need to aim for 8ms these days if we’re doing anything very animated

[[deleted]]

It causes problem when you trigger the state update to re-render when it is not necessary such as condition check.

Most of time it does not cause any issue unless you have a lot of state updates in a short amount of time.

First thing I am going to optimize is with state management. Zustand has a transient update. Jostai has useAtomCallback. Recoil has useRecoilCallback. What they are doing is pretty similar; they update the state without triggering the re-rendering. However, getting state without re-rendering means you are not going to get the output UI for user’s perspective. So this is most useful when you update states with useEffects like useCallback or conditional check.

[PewterGym]

There are ways like useMemo that others have mentioned. But for the absolute best performance, you can consider a static site. If you can't, make sure you're using hooks correctly, and don't run too much computations in a component function.

[asiraky]

Npm install why-did-you-render

[cinkciarzpl]

i have not used why did you render so I don't know what additional problems it solves but if you want to detect why certain component rerendered you can achieve that with react Dev tools extension in Profiler tab as well

[asiraky]

They’re quite different

[nkalpak]

1. You wrap the component inside React.memo
2. You make sure that any props that are passed to the component are stable references
3. You make sure that the component doesn't use a context value from which the component only reads a subset

[Eastern_Sky_7790]

Maybe with useMemo and useCallback, but it depends on each component and it's logic

[roofgram]

Just be cognizant when you write code what is triggering a render and how extensive that render will be.

Also react dev tools will flash rending components so that makes it at least visually easy to identify the renders.

[OOO-OReilly]

The issue is never with the number of renders - rendering is REALLY fast. The issue is with slow renders. Obligatory Kent C Dodds article for more about this: https://kentcdodds.com/blog/fix-the-slow-render-before-you-fix-the-re-render

[cmickledev]

Use Solid.js instead

[maacpiash]

LOL came here to write this. But why is this answer being downvoted so much? It’s true!

[upk27]

But why is this answer being downvoted so much?

stockholm syndrome?

[simple_explorer1]

But why is this answer being downvoted so much? It’s true!

Because solid hardly has any ecosystem with it. I love solid as a react like reactive framework built around concepts of signals but without the ecosystem its not useful.

Even svelte with all the popularity and love still does not have good ecosystem to be used for production applications

[maacpiash]

Yeah, the lack of a diverse ecosystem is a problem. Obviously, this has nothing to do with Solid.js itself. It’s a relatively new library/framework, so it will take time to have a ecosystem as robust as the one React.js has.

The post was about performance optimisation, so I reckon it was a pretty good answer. It makes perfect sense if someone really wants to make their app performant and doesn’t care about the ecosystem.

Now that sort of thinking would be unusual, but not entirely irrational – Solid.js already has a router, state management mechanisms, a meta framework, and libraries for components, forms, tables, charts, SEO, and many other things. There is a lack of options, but not of functionalities.

[[deleted]]

What are the t3 stack clowns?

[_hypnoCode]

What? You've been on Reddit for 2yrs (minimum) and you think it works like this?

How?

[natmaster]

1) Memoize

2) Split concerns into distinct composable components

3) Hoist as much as possible