๐ง๐ต๐ฒ ๐ฅ๐ฒ๐ฎ๐น ๐๐ผ๐๐ ๐ผ๐ณ ๐ฅ๐ฒ-๐ฟ๐ฒ๐ป๐ฑ๐ฒ๐ฟ๐ ๐ถ๐ป ๐ฅ๐ฒ๐ฎ๐ฐ๐
I used to think React performance issues came from slow APIs or bad database queries. I thought React was fast enough to handle anything.
I was wrong.
As my application grew, the UI became sluggish. The backend was fast. The network was quick. Yet, the user experience felt heavy.
The problem was not React. The problem was unnecessary re-renders.
One state update was triggering massive parts of the component tree to run again. I was asking React to do way more work than it needed to do.
Every render has a cost. React must run functions, evaluate hooks, and compare virtual DOM trees. One render is cheap. Hundreds of unnecessary renders are expensive.
I used the React Profiler to find the source. I found that many small components were rendering repeatedly.
Here is how I fixed it:
Keep state close to where you use it. I moved state down the component tree. This created smaller render boundaries. Updates stayed isolated instead of hitting the whole app.
Stabilize your references. React sees new objects and functions as changes, even if the data stays the same. This triggers child re-renders. I used React.memo, useMemo, and useCallback to stop this. I did not memoize everything. I only stabilized what mattered.
Build better rendering boundaries. Large components that handle state, data, and UI all at once are dangerous. I broke them into smaller, focused components. This made updates more targeted.
The results were massive.
A screen that took 800ms to update now takes 60ms. The app has no new features. It just stops doing useless work.
Performance is an architecture problem.
- Poor state placement creates extra renders.
- Large components create extra work.
- Unstable references create extra updates.
Stop trying to fix performance with hooks alone. Start designing better component structures.
Source: https://dev.to/akshay_sarak/the-real-cost-of-re-renders-in-react-2j77