React server side rendering performance
8 likes9,214 views
This document discusses react server side rendering. It notes that server side rendering was not originally intended in react but can provide benefits with proper architecture and performance optimizations. While challenging for performance, server side rendering can improve perceived performance through techniques like templates and optimistic updates. Overall react is still recommended, but server side rendering requires care around performance.
React server side rendering performance
- 1. react server side rendering react boston february 2015 @nickdreckshage
- 2. 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)
- 3. react made it extremely easy http://bit.ly/1yzOaul
- 4. • 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
- 5. • 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
- 7. • 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
- 8. • 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
- 9. • 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
- 10. • 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
- 11. • 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
- 12. • node limitations, value in portability • jsxtache (dont use) (http://bit.ly/1Modxtm) • compile to js? clojure? hhvm/hack? crazy ideas
- 13. • preview templates • optimistic updates • first paint? perceived performance
- 14. lets stop using the phrase perceived performance when talking about server side rendering
- 15. …so should i still use it? yes. react is awesome.