Skip to content

Instantly share code, notes, and snippets.

@vjeux
Created March 10, 2014 20:51
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save vjeux/9474059 to your computer and use it in GitHub Desktop.
Save vjeux/9474059 to your computer and use it in GitHub Desktop.
React Performance - JSFest
# Basic
Initial rendering takes ~25ms
Delete first takes ~30ms
Delete last takes ~15ms
Add `background: red` to the second element and delete the first, you'll
see that the second element is still red. What happened is that everything
moved around. The reason is that React doesn’t do the matching properly.
http://jsfiddle.net/vjeux/tXfDU/
# Key
The only change is adding `key={file}`. If you repeat the `background: red`
procedure you'll see that the background stays on the element. This means
that React diff algorithm just outputted a delete for the first one. You
can look at the key in `data-react-id`.
Initial rendering takes ~25ms
Delete first takes ~15ms <-- changed!
Delete last takes ~15ms
http://jsfiddle.net/vjeux/Z6D49/
# setState
If you click on a leaf node, it only re-render it and updates in <1ms.
But as you go up you end up re-rendering more. The root takes ~25ms.
This is a very good property as usual React apps are going to call
setState low in the hierarchy and therefore the update is going to
be fast.
http://jsfiddle.net/vjeux/7858n/
# Batching
If you click on a node, it's going to update all the nodes at the
same level using a naive loop over setState. As you can see, it
doesn't take `n` times to execute because all the setState are
being batched together.
http://jsfiddle.net/vjeux/D7G3W/
# shouldComponentUpdate
By using immutable data structure, we can implement
shouldComponentUpdate on every node. Now the root nodes are
taking <4ms. Immutable data structure is just a fancy word for
making a new copy of the object so that you can use !== to have
a fast check to stop re-render an entire tree.
http://jsfiddle.net/vjeux/RbeHa/
# Initial rendering
We managed to get all the updates <4ms but our initial rendering
is still 25ms.
- We only see 10 elements but render 500 of them. If you implement
pagination/windowing you can get ~50x performance boost.
- Render the code on the server, send the html string to the client
so he sees it very fast. Then the client downloads the js, re-executes
it and once its done your interaction is working.
# Conclusion
React is fast by default thanks to
(1) DOM diff
(2) batching and
(3) localized setState.
But no framework can get every app fast, so React gives you control
over performance characteristics with
(1) key,
(2) shouldComponentUpdate and
(3) server-side rendering.
But the most important is that we didn’t have to go back to raw DOM APIs to make it faster.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment