OK from single core $10 VPS you will be able to serve
1,080,000 unique initial loads per hour
and depending on your pattern of traffic say 15,000,000 in a day could you remind me what the issue is again?
What on earth? Our entire app is React+Redux based, gathers a bunch of unique user data per-request from various apis and we still get ~40-120ms response times (and that's on CDN cache misses).
Hell, our Node server's connection timeout is 3 seconds and we only ever hit that due an APIs tanking or something.
I would love an article detailing your experience and measurements.
First, naive server rendered React isn't diffing anything at all, it recomputes the whole virtual dom from scratch every time. So there isn't any render-tree pruning since we're not doing a diff. That's what the walmart-labs patches help with, since obviously a lot of SSR'ed components aren't changing between SSRs, that can be reused, and we can be fast again.
Second, React.js views are more than just banging html together, it also has to call a bunch of functions as part of that process. For example client side sorting, or map/reduce/filter. So if those functions are expensive, your views are slow, even if the html itself isn't all that complex.
Third, since much of our "view rendering" cost is actually computation not directly related to making html, React can't reuse pieces of those computations anyway. You'd need to code your "math" in terms of React components even though there's no html associated with them.
Fourth, if your dataflows are dynamic enough, like a spreadsheet, even if React actually could optimize those computations (which it cant), it wouldn't even be helpful, because while Views are trees, many computations are not. For example, in a spreadsheet: Edit cell C7, quick what is the tree of computations you can skip? The question doesn't even make sense, because spreadsheets aren't trees. Spreadsheets do complicated graph dependency tracking, with cycle analysis and all that, in order to make this fast. React doesn't do that.
As an example of how dynamic Hyperfiddle is, go to http://dustingetzcom2.hyperfiddle.net/ and in the top toolbar click "data" and then click "dev". Dustingetzcom2 is not coded in javascript, its coded in data, and you edit the data live in the dev pane, and the right things update live as you make changes. That's why the render computation is so expensive.
I'm sorry, I'm looking at your example link and you should be getting rendering times in the sub 40ms range. Unless that's not a representative example of course.
Nothing in there seems particularly un-reusable.
Facts are always better. Good news is: I suspect you have no React issue. How is your NODE_ENV? Set to production? After looking at your website, you have no perf issue caused by React itself! Remove the blinking cursor made with setInterval, and use CSS animation for that. You'll see :)
That link has the data points you are looking for, react SSR problems are well understood and documented and have been for some time now, that repo is a year old
also see https://www.reddit.com/r/reactssr/
As I said, our app is sophisticated
Is this how you get your kicks?
the website has its own scrollbar, on top of which chrome renders its own, and the site seems to be scrolling in place of the browser, as the "smooth-scrolling" behavior is entirely gone, as well as other little things like scrolling past the end of the page and being bumped back up
400m sessions a month doesn't really sound like that much...