DEV Community

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

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...
Collapse
 
thomasjunkos profile image
Thomas Junkツ

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

Collapse
 
stereobooster profile image
stereobooster

But I did that in 2013 with JSPs

Was it actual hydration or re-render?

Collapse
 
thomasjunkos profile image
Thomas Junkツ

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.

Collapse
 
jdsteinhauser profile image
Jason Steinhauser

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!

Collapse
 
alchermd profile image
John Alcher

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

Collapse
 
stereobooster profile image
stereobooster

First Meaningful Paint - see this image

source

Collapse
 
stereobooster profile image
stereobooster

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

Collapse
 
alchermd profile image
John Alcher

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?

Thread Thread
 
stereobooster profile image
stereobooster

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?

Thread Thread
 
alchermd profile image
John Alcher • Edited

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.

Collapse
 
stereobooster profile image
stereobooster

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.

Collapse
 
stereobooster profile image
stereobooster

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.

Collapse
 
gijovarghese profile image
Gijo Varghese

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

Collapse
 
stereobooster profile image
stereobooster • Edited

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.

Collapse
 
gijovarghese profile image
Gijo Varghese

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

Thread Thread
 
stereobooster profile image
stereobooster

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

Thread Thread
 
gijovarghese profile image
Gijo Varghese

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

I'll correct it

Collapse
 
themindfuldev profile image
Tiago Romero Garcia

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.

Collapse
 
svedova profile image
Savas Vedova

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)

 
mantis4444 profile image
mantis4444

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.

Collapse
 
papaponmx profile image
Jaime Rios

Great post, thanks for sharing!

Collapse
 
smrb76 profile image
seyed mohamad reza bazrgari

If your server in Europe, but client is in Japan SSR will not help you here
WHY?

Collapse
 
justin808 profile image
Justin Gordon

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.

Collapse
 
stereobooster profile image
stereobooster

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

Collapse
 
pizmovc profile image
Luka • Edited

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.

Collapse
 
stereobooster profile image
stereobooster

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.

Collapse
 
j__kettmann profile image
Johannes

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.