DEV Community

Cover image for The tribulations of React performance optimizations
Fred B.
Fred B.

Posted on

The tribulations of React performance optimizations

As I see it occuring so many times in the industry, it so happens that many developers do anticipate performance issues while still in early development stages of an application project.

And this, even prior to running the app on a production-like environment !

This strategy often ends up being the same as shooting oneself in the foot.

Why you say? Because optimizations always come with a cost!

Use case: code-splitting

Is spreading the total loading time of the app always a good idea? Is splitting the code and lazy-loading the different chunks, always a good solution? Every time? No matter what?


  • Are those chunks really heavy enough to justify having the spinning wheel of death appear everytime the user clicks on a link?
  • Or should you rather have an app displaying a longer intial loading time but which, once fully loaded and cached, responds swiftly to all user interactions?
  • Are your end users from the general public, or are they B2B customers? Sure users in general don't like to wait of course, nobody does, however:
    • B2B users might not have a choice than to be using your app, so if there is no budget for optimization, then intial loading time can be "imposed" upon them with minimal business repercussions;
    • On the other hand, public users, C2B users, WILL go away and shop somewhere else if your e-commerce app takes too long to load, having a real impact on business revenue in the short or medium term

What to look out for

  • After a hard reload, meaning you got rid of all cached elements, and after applying a given optimization, is the app starting faster during its initial render?
  • Is this really the only criteria to consider ?
  • What are you trying to achieve?
    • Do you want users to feel that your app loads fast?
    • Do you want the app to respond quickly to user interaction?

Sure! We all want both, but again, at what cost?

But most importantly :

  • does it depend only on what YOU want or think as a developer ?
  • what if the target machine is a smartphone, can you afford to have many http requests, knowing how it impacts battery life ?
  • what if there is no budget for optimization ?
  • what is the hosting plan in production, and what is the cost related to hitting your server by an increased amount of http requests ?

So what is the solution?

We must be able to evaluate the cost of the optimization by clearly identifying what was lost and what was gained.

It's all about the tradeoffs baby!

Step #1 - Diagnose

So, let's first run the app we are working on, and IF we find that the app starts too slowly, or a certain component takes too much time to mount or render, THEN let's diagnose the problem.


Step #2 - Measure

So let's measure the problem.

  • How much time do components take to mount or render?
  • How much time is a function taking to run ?
  • Is there some JS or CSS resource blocking the intial app rendering ?

Check out Progressive React for details on measuring using different tools.

Step #3 - Identify & Apply optimization

After diagnosis and measurement, the right optimization strategy should form. This allows to identify the appropriate optimization technique(s) for the particular situation we're trying to solve. So, here's when we apply an initial solution.

Step #4 - Measure again & Compare

Lastly, let's measure once again to ensure that the optimization cost was worthwhile.

How? By comparing the new measure to the original measure, the one we took while diagnosing the problem.


All in all, these are examples only of considerations to take into account even before we start optimizing just for the sake of it.

The right optimization strategy is far from being a "simple" technical-only subject, and depends at least on:

1) budget,
2) the nature of the app,
3) end users (& stakeholders at large),
4) the end users' target machines
5) technical requirements of the production environment

Final words of caution about optimization in general

So, let's not optimize for the sake of it.

Meaning, let's not memoize or avoid inline objects systematically (React.useMemo & React.useCallback).

Let's not split our code and lazy load it systematically (React.lazy + React.Suspense + Spinner + ErroBoundary).

Let's not memoize components systematically (React.memo, React.PureComponent, shouldComponentUpdate).

In order words: consider the act of optimizing ONLY if there is a performance problem or complaint in production!

Bonus: Recommended Toolchains

The React team primarily recommends these solutions:

  • If you’re learning React or creating a new single-page app, use Create React App.
  • If you’re building a server-rendered website with Node.js, try Next.js.
  • If you’re building a static content-oriented website, try Gatsby.
  • If you’re building a component library or integrating with an existing codebase, try More Flexible Toolchains.

Top comments (0)