Server Side Rendering vs Static Site Generation vs Incremental Static Regeneration
Tags: gatsby, react, saas, serverless
Published: 2020-02-19 14:57:09

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**.
Lately Incremental Static Regeneration (ISR) by Next.js offers a third way that's a sort of hybrid between the other two.

Here I show the reasons to choose SSR, SSG or ISR for you next project, in particular for the [React](https://reactjs.org) 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](https://nextjs.org) (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](https://www.netlify.com). 

The problem is that the **content becomes stale**, so you need to rebuild the website pages to update it. [Netlify](https://www.netlify.com) or [Zeit Now](https://zeit.co/) 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](https://www.gatsbyjs.org/) and [Next.js](https://nextjs.org) (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

# Incremental Static Regeneration:
ISR is a new paradigm introduced by Next.js starting from v9.5. **It combines the advantages of static generation** (very quick response time) **and server rendering** (fresh data, ability to have >100K pages).

How does it work?
- Next.js will do **server-side rendering for every page that is not already statically generated or that is stale** (you can set the stale time via the `revalidate` prop in `getStaticProps`).
- When a page is requested, if there is already a stale static page, that page is served immediately and in background a new fresh page is statically generated on the server to be served to the next request (**stale-while-revalidate caching strategy**).
- If there is not a static page already generated, Next.js generates it server-side and saves it as a static page to be served immediately to the next request.
- When Next.js needs to do SSR to generate a page the first time, you can choose to wait the SSR to complete (preferred) or have a **fallback** (skeleton page with a loading indicator) while loading data.

### Example strategy
Suppose that you have an **e-commerce site with 50.000 products**: you could decide to have **the 2.000 best sellers statically generated** (the build time won't be too long) so that they are always served very quickly. The other products' pages (the "long tail") will have a slower response time just for the first request, then they will be statically generated for the subsequent requests.

### Pros:
- Really fast website, as most times the user will be served a static page
- Fresh content, as you can set the max stale time
- It works with a very big website, too (100K, or 1M pages)

### Cons:
- The first requests to pages not already statically generated may take a while
- After the stale time, the first request may still get stale content while revalidating the cache

# 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

**In that cases I'd choose Next.js incremental static regeneration.**

> NOTE: I created a CMS with Visual editing for React, called [React Bricks](https://reactbricks.com), which works with every strategy (SSG with Next.js and soon Gatsby, SSR or ISR with Next.js) 🚀
> It is great for Developers (content blocks created as React components) and for Content creators (visual editing experience). I suggest you to do the [Tutorial with gamification](https://reactbricks.com/learn) and Tweet the score you got! 😊