Server side rendering (SSR) and Static Site Generation (SSG) are two ways to create websites using a modern front-end stack (getting content from a server API) while preserving SEO friendliness and perceived performance.

Here I show the reasons to choose SSR or SSG for you next project, in particular for the React ecosystem.

Server Side Rendering

With SSR, the website pages are generated at runtime on the server.
This means that the server must be able to execute Node.js to generate the pages.
The advantage is that the pages are always up-to-date, but every page view triggers a call to the APIs.

Pros:

• Content is always up-to-date
• No need to trigger a rebuild of the website when content changes

Cons:

• Cannot deploy to a static CDN
• The Time-To-First-Byte is a bit slower because the content is generated on the server for each request

How to cope with cons:

• You may always put a caching layer, like a Varnish server with a short TTL, in front of your website to improve the response time
• Next.js (a framework for SSR with React) understands when your pages don’t need data (no getInitialProps static method) and creates pure static pages that don’t need server processing

Static Site Generation:

With SSG, all the pages are generated at build time as static pages (with some Javascript tricks to load/preload content as fast as possible). The Time-To-First-Byte is the best you can get and you can host your website on a static hosting platform like Netlify.

The problem is that the content becomes stale, so you need to rebuild the website pages to update it. Netlify or Zeit Now provide hooks to trigger a rebuild from a remote app, like a CMS.

Since you call the APIs only at build time, you end up calling them fewer times in a day, so that, if you have a cap on the number of API calls, you don’t risk to exceed it.

The main SSG technologies in the React ecosystem are Gatsby and Next.js (which can do both SSR and SSG).

Pros:

• Really fast website
• Can deploy to a static CDN
• Security: the attack surface of a static website is minimal
• Fewer API calls

Cons:

• If content changes frequently, it may become stale
• Need to trigger a rebuild to update content
• If you have a really big website, build time may be very long

How to cope with cons:

• When you have both stable data (for e-commerce: product description, images, etc.) and frequently changing data (stock quantity) you may do an API call on component load to fetch an updated version of just the frequently changing data. Search engines could crawl the stale data, but it’s not a big problem in this case
• Using this technique, you may also manage authentication and serve a different content to different users

Conclusion

Today I'd choose a static site anytime, unless:

• the website is very big (for example a 50K products e-commerce)
• the content changes very frequently and the user needs it up-to-date

NOTE: We'll soon release in beta testing a block-based hybrid CMS called React Bricks, which will work with both SSR (Next.js) and SSG (Gatsby or Next.js), so… stay tuned!