Performance optimisations for React applications – Alex Reardon – Medium

Performance optimizations for #ReactJS apps:

  • It is the responsibility of this function to return true if the component should update and false if the component should not update.
  • Using tools will help you find performance hotspots specific to your application.
  • Anything else you can think of that avoids creating a new function every time render is called!
  • Every component in React has a shouldComponentUpdate(nextProps, nextState) function.
  • Generally applications want to promote loose coupling (components know as little about other components as possible).

The main performance hotspot in React applications is redundant processing and DOM diffing in components. In order to avoid this return false from shouldComponentUpdate as high up in your application…

@ReactiveConf: Performance optimizations for #ReactJS apps:

The main performance hotspot in React applications is redundant processing and DOM diffing in components. In order to avoid this return false from shouldComponentUpdate as high up in your application as you can.

Let’s take a look at how React renders components

On the initial render we need the entire application to render

Every node has rendered — this is good! Our application now represents our initial state

We want to update a piece of data. This change is only relevant to one leaf node

We want to only render the nodes that are along the critical path to our leaf node

Oh no! All of our nodes have rendered.

Every component in React has a shouldComponentUpdate(nextProps, nextState) function. It is the responsibility of this function to return true if the component should update and false if the component should not update. Returning false results in the components render function not being called at all. The default behaviour in React is that shouldComponentUpdate always returns true, even if you do not define a shouldComponentUpdate function explicitly.

This means that by default every time you update your top level props every component in the whole application will render. This is a major performance problem.

Ideally we do not want to be doing deep equality checks in our shouldComponentUpdate functions as they are expensive, especially at scale and with large data structures.

An alternative approach is to change an objects reference whenever it’s value changes.

Why make things hard for yourself? You want these checks to be so easy that you do not need to really think about them.

Generally applications want to promote loose coupling (components know as little about other components as possible). Parent components should have as little understanding as possible about how their children work. This allows you to change the children’s behaviour without the parent needing to know about the change (assuming the PropTypes remain the same). It also allows children to operate in isolation without needing a parent to tightly control it’s behaviour.

By denormalizing (merging) your data structure you can go back to just using really simple reference checks to see if anything has changed.

Usually we do not create new props inside a component to just pass it down. However, it is more prevalent to do this inside of loops

eg:

All of the rules and techniques listed above were found by using performance measuring tools. Using tools will help you find performance hotspots specific to your application.

Using this method you can record the time taken for every action and its resulting render in your application. You can quickly see what actions take the longest amount of time to render which gives you a good place to start when addressing performance concerns. Having time values also helps you to see the what difference your changes are making to your application.

Similar to the console.time method this will let you see performance metrics for each of your actions. For more information on the React performance addon see here

CPU profiler flame charts can also be helpful in finding performance problems in your applications.

Firefox: see here

Performance optimisations for React applications – Alex Reardon – Medium