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

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, but I guess it will make sense for other frameworks too.

You need SSR if you care about:

• First meaningful paint. SSR alone doesn't guarantee good results. You also need critical CSS and proximity to the client etc.
• SEO and support other bots like Twitter and Facebook
• Graceful degradation. For this one, you need to make sure your service is usable without JS

What is hard about it?

SSR is like a new dimension. Whatever you use you will need to reconfigure it for SSR.

• Do you use componentDidMount to fetch the data? You need to use something like getInitialProps (from next.js or after.js) or state management library like Redux to make it work on the server
• Do you use Router? You need to configure it on the server
• Do you use i18n? You need to configure it on the server
• Do you use HMR? You will need to reload code for browser and for the server
• Do you use react-helmet? You need to configure it on the server
• Do you use react-loadable? You need to configure the server to pass used modules, so the client can preload them
• Do you use Redux? You need to serialize store and pass it to the client
• Do you use CSS-in-JS? You need to configure it to generate critical CSS on the server and inline it in HTML response

Don't get me wrong this is all solvable. Next.js and Razzle solve most of those issues. What I want to show you is how SSR kind of doubles everything (another dimension) and most of the time requires boilerplate for everything.

Ok. Now let's get over benefits.

First meaningful paint

If you are doing SSR, it doesn't mean you will get good first meaningful paint out of the box.

• Does your setup have a good Time to the First Byte? If your server slow or overloaded - you will have issues. Make sure to use the latest node, minify server code, use streaming rendering, optimize subqueries (database or network) if any.
• Do you provide critical CSS? Otherwise, the browser can't start to render the page.
• Do you use web fonts? If yes, do you optimize it?
• Is your server close to the client? If your server in Europe, but client is in Japan SSR will not help you here. It can happen that serving "shell" from CDN will be faster (from the impression point of view) than doing SSR. What if you can not move server closer to the clients because of legal limitations?
• Did you make sure you don't have unnecessary redirects? Otherwise, redirect on slow 3G will ruin your hardly gained milliseconds.

SSR is not a silver bullet for the First Meaningful Paint. If your backend is slow or far away you need to check if "shell" and CDN would work better. You can use something like react-snap to prerender static pages and generate a "shell" for other pages.

If your website tends to be more static you can use prerendering instead of SSR. Check out react-static or gatsby or react-snap.

SEO

There are 3 options here:

• SSR
• Prerendering, like react-snap, react-static, gatsby etc.
• Prerendering on the demand, like rendertron, puppetron, pupperender etc.

Choose prerendering if you can. Prerendering on the demand is easy to add at any moment if your only concern is SEO.

Graceful degradation

This one is tricky. This really depends on how much degradation you want to achieve?

• Do you want to support links? This suppose to work
• Do you want to support drop-down menus, like they do in https://www.seek.com.au/? You need to use some tricks with CSS and checkboxes
• Do you want support forms? You need endpoints to handle those forms, in addition to existing JSON API

Some functionality without JS is pretty hard, like combo boxes or maps

Conclusion

SSR is good, give it a try. Also, make sure your users actually benefit from it.
If you can't use SSR try prerenderers, sometimes it is the easiest option.

Follow me on twitter and github.

Comments

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

[stereobooster]

But I did that in 2013 with JSPs

Was it actual hydration or re-render?

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

[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!

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

[stereobooster]

First Meaningful Paint - see this image

source

[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

[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?

[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?

[John Alcher]

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.

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

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

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

[stereobooster]

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.

[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

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

[Gijo Varghese]

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

I'll correct it

[Tiago Romero]

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.

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

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.

[Jaime Rios]

Great post, thanks for sharing!

[seyed mohamad reza bazrgari]

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

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

[stereobooster]

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