What this article <i>should</i> have linked to: <a href="https://github.com/walmartlabs/react-ssr-optimization" rel="nofollow">https://github.com/walmartlabs/react-ssr-optimization</a><p>> After peeling through the React codebase we discovered React’s mountComponent function. This is where the HTML markup is generated for a component. We knew that if we could intercept React's instantiateReactComponent module by using a require() hook we could avoid the need to fork React and inject our optimization. We keep a Least-Recently-Used (LRU) cache that stores the markup of rendered components (replacing the data-reactid appropriately).<p>> We also implemented an enhancement that will templatize the cached rendered markup to allow for more dynamic props. Dynamic props are replaced with template delimiters (i.e. ${ prop_name }) during the react component rendering cycle. The template is them compiled, cached, executed and the markup is handed back to React. For subsequent requests the component's render(..) call is short-circuited with an execution of the cached compiled template.
The headline should've been "it takes 150ms to do server-side rendering with React," not, "hey everyone I can put something in Redis." I would _not_ take this person's advice. There's most likely something else really wrong with their code.<p>Also.... 20ms with caching the pages in Redis? That sounds really, really slow. There's definitely something else going on.
> For this, we created a small param cache=false. Whenever the url is hit with this URL, the node server makes and API call instead of fetching data from the redis cache. And hence the cache is updated with the newer data.<p>> Whenever you deploy, new chunk hash for js and css files gets generated. This means if you’re storing the whole HTML string in the cache, it’ll become invalid with the deployment. Hence, whenever you deploy, the redis db needs to be flushed completely.<p>These arguments sound like over-engineered "solutions" by somebody who did not do their homework. To speed up your SSR, render components, not the _whole_ page. Vast majority of your page is going to remain constant: the head, navigation, footer. Rendering these components in partials will save you the Redis store by a very, _very_ large margin. Once they start caching hundreds of thousands of HTMLs, the Redis server will start swapping the content from memory to the disk. There, you just defied the whole point of using Redis.<p>Also, your users are _still_ going to see the 810ms latency the first time they access your service. How often do you think they'll be reloading right after the page is loaded? And once the cache is invalidated -- which I suppose would happen frequently -- the _visible_ latency is still high.
At the point where you're able to cache the exact HTML you're returning to the client, it's more efficient to do that in front of your node server than behind it. A cache hit can avoid your application completely, which is a real boon for performance and scalability. You can run your own caching http proxy, like varnish, or use a CDN like Fastly.
This makes me wonder how many people are using AJAX as an excuse for slow response times. If >500 ms isn't acceptable for a full page load then it shouldn't be acceptable for an AJAX REST call either. A page showing a spinner instead of content isn't any more useful to the user than a blank page.
If your HTML is cacheable: You just need to set your HTTP header's appropriately.<p>You can also invest in a CDN. Now we have a React.js SSR with 0ms server response time! :)
> 150 ms for server side rendering<p>that's really really really bad for generating a html (and even sending it to the user).<p>I can achieve the whole damn thing in 20ms or less.<p>> The average response time fell to 20 ms !<p>yep in java/go/whatever you don't need the cache, with it your avg response would drop even further!
The title reminded me of react-dom-stream[0] which is accompanied by this great talk[1]. Went back to see if some parts of it landed to the core[2] but it hasn't seen any progress as of late. Oh well.<p>[0]: <a href="https://github.com/aickin/react-dom-stream" rel="nofollow">https://github.com/aickin/react-dom-stream</a>
[1]: <a href="https://www.youtube.com/watch?v=PnpfGy7q96U" rel="nofollow">https://www.youtube.com/watch?v=PnpfGy7q96U</a>
[2]: <a href="https://github.com/facebook/react/issues/6420" rel="nofollow">https://github.com/facebook/react/issues/6420</a>
This article mentions SEO.<p>As far as I know, as long as the content is embedded in JSON/JS when the page loads, it's fine to then "render" it with JavaScript. It's 2016 and Google started crawling JS websites a while ago.<p>However, if you fetch it with AJAX after the page loads, Google won't see it because it doesn't necessarily follow AJAX calls nor wait around for them to return in 810ms. They'll most likely only render the bundled content.<p>You can use the "fetch as Google" tool in Google Webmaster Tools to try this out for yourself.