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 about React... [Read Full]
markdown guide
 

Nice article. It's quite sad though you talk about SSR without explicitly pointing out that this only works with a node server and therefore, you don't talk about alternatives regarding other types of servers & backend languages.

Alternatives are:

  • Prerendering (obviously works too)
  • Putting a node server in front of your initial server and proxy api calls
  • Using $V8js module on PHP if you use PHP
  • As someone said below, just do a regular website like we always did with backend languages, stringify then hydrate your React, Vue or any SPA framework app with the data. (this solution can be quite challenging though).

In summary, if you have a server thats is NOT node, you pretty much want to go with prerendering. I would even say prerendering is most of the time the best bet.

SSR is IMHO overkill for many apps, but people like to put it to be "in the futur" if you know this reference :)

Great article though.

 

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.

 

yes that is a good way to go. BUT! (haha always a "but"), if you have a lot of traffic and a load balancer, your load balancer will have x2 requests each time, one from the client (browser) to the render server, and one from the render server to the API server.

Which means, if you have 1Millions http requests, you end up with 2Millions request, and that may cost a lot and be quite slow as there are 2 hhtp request for only one page asked by the client.

A way to breaj that is to have both servers on the same machine and do the inner communication through direct IP instead of a dedicated domain name to reduce domain resolving.

 

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 :/

 
 

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.

 

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.

 

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)

 

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.

 

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!

 

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

 
 

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 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.

code of conduct - report abuse