React server side rendering performance
-
Upload
nick-dreckshage -
Category
Engineering
-
view
881 -
download
4
Transcript of React server side rendering performance
![Page 1: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/1.jpg)
react server side rendering
react boston february 2015 @nickdreckshage
![Page 2: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/2.jpg)
isomorphic is a pretty sexy word…
• …for shared code. spectrum: templates -> meteor.
• got into it with rendr / spikes talk (http://bit.ly/1MoAzjZ)
• experimented making ‘isomorphic’ on npm
• frontend trend / direction (backbone, react, ember)
• word not cool anymore? oh well (http://bit.ly/1CxzIFy)
![Page 3: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/3.jpg)
react made it extremely easy http://bit.ly/1yzOaul
![Page 4: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/4.jpg)
• node as a ui layer (http://bit.ly/1bjOXb3)
• not too many abstractions (webpack, superagent, etc)
• careful with context (http://bit.ly/1EewJEn)
• react router; react nexus
• relay / graphql
workflow
![Page 5: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/5.jpg)
• 1 lookup; 1 event binding; 0 repaints
• base10 numbering; adler32 checksum
• high level (virtual dom; synthetic events)
• low level (jquery killer bees)
• larger html payload. html + json data + async js
smart server side rendering
![Page 6: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/6.jpg)
sounds perfect…
![Page 7: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/7.jpg)
• not great!
• simple experiment (http://bitly.com/1yzOaum); 1mb json; 1000 items; a few components / partials.
• ab -c 1 -n 100; mean response time on slow macbook air
server side performance
react (node) react* (node) hogan (node) mustache (go)
1250ms 650ms 450ms 30ms
*using best practices
![Page 8: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/8.jpg)
• http://bit.ly/1DxGdfx
• “funny story about server rendering - it wasn’t actually designed that way” (Sebastian Markbåge)
• “we don’t use it that heavily, which is why we haven’t really invested strong in it” (Sebastian Markbåge)
• improvements: autobinding, ignoring state
q&a @ react conf
![Page 9: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/9.jpg)
• primary concerns: architecture + performance
• server side rendering a bonus (with great architecture)
• facebook doesn’t use server side rendering in prod (tmk)
• instagram did, then abandoned it (http://bit.ly/1FPekyY)
• transparency > collective ignorance
a secondary concern
![Page 10: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/10.jpg)
• netflix switching all platforms to react
• facebook mobile (server rendered; relay / graphql)
• e-commerce? non-single page apps?
• bbc mobile (http://bit.ly/1Ab0uoD)
• flipboard (http://bit.ly/1zTrFnK)
• ssr performance as final barrier. then no downside?
growing importance
![Page 11: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/11.jpg)
• use node. not ruby racer / php v8js
• compile jsx / webpack for server?*
• NODE_ENV=production*
• require(‘wrapped-react’)*
• cluster.fork()
• cache (um…)
best practices
*http://bit.ly/1AF4yiP
easy 1250ms
+ compile jsx 1240ms*
+ NODE_ENV 990ms
+ wrapped 650ms
+ cluster **
+ cache 30ms!
* increases with # of components ** basic load balancing
![Page 12: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/12.jpg)
• node limitations, value in portability
• jsxtache (dont use) (http://bit.ly/1Modxtm)
• compile to js? clojure? hhvm/hack?
crazy ideas
![Page 13: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/13.jpg)
• preview templates
• optimistic updates
• first paint?
perceived performance
![Page 14: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/14.jpg)
lets stop using the phrase perceived performance when talking about server side rendering
![Page 15: React server side rendering performance](https://reader035.fdocuments.us/reader035/viewer/2022071705/55a7887f1a28ab7c188b492b/html5/thumbnails/15.jpg)
…so should i still use it? yes. react is awesome.