Server Side Rendering pros and cons. When to use it and when to choose something else.
stereobooster Sep 14
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
componentDidMountto 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.
There are 3 options here:
- 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.
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
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.