Server Side Rendering pros and cons. When to use it and when to choose something else

stereobooster on September 14, 2018

Photo by Daniel H. Tong on Unsplash What is SSR and why should you care? SSR stands for Server Side Rendering. I will talk mostly abo... [Read Full]
Editor guide

As interesting this topic is - didn't we have this in the 2000's? Where all these rich serverside frameworks emerged? What I find a smart move is to serve a basic - perhaps even statically prerendered - version of the site and hydrate it on the client. But I did that in 2013 with JSPs, where I painted everything needed already on the page; including a script tag with serialized JSON to have an initial state going.

Don't get me wrong: I like the idea moving towards a Jam Stack, but it is something like new vine in old bottles :]


But I did that in 2013 with JSPs

Was it actual hydration or re-render?


It wasn't called hydration at the time. What I did was rendering an initial state of a document, put a script block inside where the state was rendered as a variable - simply an object, which was then picked up by backbone to get the frontend going.

That gave me a fast startup and a fully SPA-like UX in a traditional multidocument application.

We moved an existing application from traditional serverside baked in the early 2000s to a more modern version, where you had small SPAs so to say.

Unfortunately I left in 2015. So I can't tell how it came out. But a full SPA would only be consequential. 😉

So in a sense we played at the time with such types of concepts already.

Only, that you could now dismiss fully fledged web frameworks and go with Gatsby or vuepres mix and match with APIs living in AWS or on premise.


I'm quite ashamed that there's a lot of terms here that I don't fully understand. Oh btw, that cover photo is spooky once your post reached the top :/


First Meaningful Paint - see this image



I'm ashamed that you feel like that. I didn't try to sound smart, it's just how I call it at work. Please don't feel like that. I will try to explain some of those, feel free to ask questions. This post was more like I thought out loud about pros and cons. I guess this type of posts are not beginner friendly


Thanks for the thorough follow up! I'm not really huge into the JS ecosystem so SSR is still hazy. So let's say I built a React implementation of a shopping cart and stuff it into a shopping-cart.js. If a client issues a GET request to /shop, I build a template, include the relevant HTML and CSS and of course the JS file, and return that to the client. How is SSR different from that?

You know how typical React based website looks like - there is html with header, scripts, styles but without actual content, like it has <div id="main"></div> where React will be mounted as soon as application loads in the browser. With SSR this div will be prefilled with HTML, the same one as React would generate in the browser, but now it is done on the server. Make sense?

Oh yeah I get it now. "rendering" in this context pertains to the ReactDOM.render(document.getElementById('root'), <ShoppingCart />); which happens on the server as opposed to being done once the client loads the page.


SSR - server side rendering. React components kind of decoupled from render implementation, so you can use rect-dom in the browser and it will generate DOM nodes, but it will generate strings on the server. This decoupling allows you to render React applications on the server. Please tell me if I failed to explain. Side note: there are also renderers for native applications, for Canvas, for terminal.


Graceful degradation - is when you develop for modern browsers first and for less modern browsers (category which also includes browsers with disabled JS) you provide less features, but still it is decent experience, not something broken.


There's a lot more attention being paid to SSR lately. Server-side React has definitely been one way to do it, but others have taken a nearly no JavaScript necessary approach, such as Texas for Elixir/Phoenix. Excellent read!


Great post! One thing I would add is SSR matters a lot when using Web caching / CDNs such as Akamai. It means we can skip going to the origin of the data to request and build these pages and highly reduce the load on the data services.

Unless we are talking about non-cacheable data, like the user data, but for these then client-side rendering can be more appropriate.


Nice thoughts. I've actually left SSR due to many reasons. I've written a blog post about it. Can you look into it and share your thoughts? coffeencoding.com/why-ssr-is-not-a...


It has similar ideas and I generally agree, except one bit

Google and other search engines use a ‘real’ browser to index your pages.

Not quite correct. It has two phases, and first phase is done without browser. So prerendered pages get indexed faster. Google uses Chrome 40-ish for indexing, so it means your SPA should work in Chrome 40-ish. A lot of SPAs don't provide polyfills for it and basically fail to render, and googlebot sees JS error instead of content. So prerendered content (SSR or prerendering) is always a safe bet.


The last time I checked, Google is using Chrome 54. I have a few websites without SSR, there haven't been any problems with indexing.

But yes, if your site has thousands of pages, SSR can improve indexing speed

Googlebot uses a web rendering service (WRS) that is based on Chrome 41 (M41). Generally, WRS supports the same web platform features and capabilities that the Chrome version it uses — for a full list refer to chromestatus.com, or use the compare function on caniuse.com.

source: developers.google.com/search/docs/...

Oops! sorry, somewhere I read it's 54. My mistake!

I'll correct it


I actually wrote a tool that has support for server side rendering. It's like Netlify, but with SSR support.

The advantages are:

  • No need to write a webpack configuration for the server. It figures it out by itself.
  • No need to think about setting up a node server, maintaining it and scaling it up.
  • With a few lines of code you can server side render a basic app.
  • It also works with complex cases (tested on tutti.ch)

Check it out: stormkit.io (It's currently in its alpha stage)

Guys just put Varnish in front of everything and forget about multiplying requests. The first load will do the calculations and all the other times it will return already generated desired http response string without even waking up a web server.

I know I know every app has different needs, you cannot just do full page caching, it depends on session, cookies and etc. But if you invest time in configuration it right (with Varnish it can be pain in da a$$), you can achieve an amazing performance.

Maybe HTTP caching is a bit off topic here, but I think it can be really good friends of SSR.


Great post, thanks for sharing!


I think you should explain in a bit more detail what are SSR, First Meaningful Paint and Graceful degradation for someone that is not familiar with it.


Thanks for the comment. I guess title and content misaligned a bit. This is more pros and cons article instead of introduction for the beginners. I can add definitions, but this wasn't initial purpose of the article. I will change title appropriately.


Hi! Thanks for the article. Did you ever take a look at github.com/shakacode/react_on_rails? Lots of sites with Rails backends have server-side rendered React.


I don't get to work with Rails a lot recently, but otherwise I guess this is a good choice


I like to use a dedicated render service and a separate API service. You can run the rendering on a node server or serverless. The API might use a totally different technology in this case.

Code of Conduct Report abuse