Created
March 10, 2014 20:51
-
-
Save vjeux/9474059 to your computer and use it in GitHub Desktop.
React Performance - JSFest
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# 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