Server Side Rendering vs Static Site Generation vs Incremental Static Regeneration

Intro

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

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.