Server Side Rendering vs Static Site Generation vs Incremental Static Regeneration

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.

NOTE: I created a CMS with Visual editing for React, called React Bricks, 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 and Tweet the score you got! 😊

Comments

[Rolf Streefkerk]

With AWS tou can actually use CloudFront caching for dynamic serving content, it has TTL mechanisms to cope with it. So there are ways around the issue.

Look here for some use cases,
aws.amazon.com/cloudfront/dynamic-...

[Phil Ashby]

In my experience, the major reasons for looking towards SSG rather than any form of active server (SSR, Wordpress, Wiki's, etc.) are: security, static content has nothing to attack outside the base web server, which is typically a very well tested off-the-shelf option; cost saving, typically one can host static files in S3 or Azure storage for 10% of the cost of a hosting a VM.

Personally I'm moving from Wordpress and MoinMoin to static sites with Hugo for these reasons.

[Matteo Frana]

I totally agree with you.
After a period converting Wordpress sites to Gatsby with Wordpress REST and Admin, we decided to build our "React Bricks" CMS (based on React Components) to avoid Wordpress altogether.
We'll release it in beta soon; we have already used it for 3 sites and we love the new way of working with Gatsby/Next SSG and our CMS.

[Aabhas Sao]

Thank you, I was able to understand difference between SSR and SSG clearly after this.

[Mohamed Khaled]

i have a confusing about SSG
do we can make api calls on run time or not because you said "Since you call the APIs only at build time"
and them at the end in "How to cope with cons:" section you said
"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."

and even authentication on SSG websites it needs api calls to server to sign up or sign in or fetching user data

so please clear it to me.

[Nikolai56]

What about the Netlify CMS? Aren't you guys trying to do the same?

[Matteo Frana]

No, it's different: in NetlifyCMS you edit the content in a form and you have the preview on the side. With React Bricks you edit directly the content through the React components created by you (using React Bricks WYSIWYG components Text, RichText, Image) and the editing page is really the same as what you'll get in the frontend, because the frontend is created by React Bricks's Viewer component.
We have prepared starters for both Gatsby and Next.js.

What's more, you don't have to use components like Gatsby Image, because React Bricks has its own cross-platform Image component (with lazyload, srcSet, etc.).

Migrating from Gatsby to Next or viceversa is just a matter of cloning another starter, copying ApiKey and AppId and the block schema.

BTW, we are launching tomorrow in beta!! :)