Most of our pages on walmart.com are using server side rendering (henceforth SSR) with only a few unique exceptions.

We are using server side rendering for two reasons:

Performance benefit for our customers

Consistent SEO performance

Due to the benefits of SSR, when we transformed our stack to React and Nodejs, we put a lot of time and effort in optimizing SSR performance. One of our key metrics for measuring performance is “above the fold” render. Our Electrode framework that we open sourced has multiple modules to improve the performance of SSR and I blogged previously about the benefit of those modules.

When we announced Electrode and its focus on SSR, I received tons of questions and comments asking about the benefit of SSR. This blog post focuses on the performance benefit of using SSR — Andrew Farmer and Patrick Hund did a great job covering the SEO benefits.

The Theoretical Performance Benefit

Here is a very simple timeline diagram(super simple)to showcase the difference between SSR and CSR.

The main difference is that for SSR your server’s response to the browser is the HTML of your page that is ready to be rendered, while for CSR the browser gets a pretty empty document with links to your javascript. That means your browser will start rendering the HTML from your server without having to wait for all the JavaScript to be downloaded and executed. In both cases, React will need to be downloaded and go through the same process of building a virtual dom and attaching events to make the page interactive — but for SSR, the user can start viewing the page while all of that is happening. For the CSR world, you need to wait for all of the above to happen and then have the virtual dom moved to the browser dom for the page to be viewable.

Another Bonus: The blank page flicker that happens with CSR also doesn’t really happen with SSR — though most people avoid it by having a loading image sent down in the server response which is removed when everything is done loading.

Now, there are a few caveats:

While the page is rendered earlier and the customer can see the page sooner, they can’t really interact with it until react is done executing. If the customer is really fast and clicks a button, the action won’t be executed until React is done executing;

SSR TTFB(Time To First Byte)is slower than CSR, because your server will have to spend the time to create the HTML for your page instead of just sending out a relatively empty response;

SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which means the server will not be able to process any other request till ReactDOMServer.renderToString completes. Let’s say that it takes you 500ms to SSR your page, that means you can at most do at most 2 requests per second. *BIG CONSIDERATION*

Real Use Case

Below are production applications of walmart.com rendered with SSR vs CSR.