Understanding Next.js Rendering Strategies — SSR, CSR, SSG & ISR

Next.js 13

One of the advantages of using Next.js is the versatility in regard to how it builds the page on the user’s browser. If you can comprehend how these strategies work, you will have an easier time building a faster and more efficient site.

Next.js has four rendering strategies:

• Server-Side Rendering (SSR)
• Client-Side Rendering (CSR)
• Static-Site Generation (SSG)
• Incremental-Statis Regeneration (ISR)

I will break down each strategy with points such as the process behind the scene, the use case, and the pros & cons.

Server-Side Rendering

Server-Side Rendering flow

How it works:

• The JS file is sent to the server
• When the user (browser) requests, the server will run the getServerSideProps() function (Next 12) or fetch(‘https://...', { cache: ‘no-store’ }); (Next 13)
• After the data is fetched, it will be built on the server (including the data from the API)
• The server will send the HTML to the user’s browser

Use-case:

• If your site data is updated frequently
• While at the same time, SEO is an essential factor as well

Pros

• No loading
• Real-time data
• Good for SEO
• It can be used for personalized content

Cons

• The user needs to wait for the HTML to be built on the server-side
• Too much burden on the server ⇒ every user’s request, the server needs to rebuild

Client-Side Rendering

Client-Side Rendering flow

How it works:

• Build process ⇒ The HTML file is sent to the server
• When the user requests, the server will send the HTML file, then the client (browser) requests the data to the API server

Note: In Next 13, you need to add ‘use client’at the top of your jsx/tsx file to let Next.js know it’s rendered on the client side.

• At the time the client is requesting data from the API server, the browser will display the loading-state (in most cases)
• After the data is fetched from the API server, then the loading-state will be turned off and the screen will be updated with the data from the API

Use-case:

• If your site’s data is updated frequently
• SEO is not an essential factor

Pros

• Real-time data
• It can be used for personalized content
• The burden is not too big for the server

Cons

• There will be a loading-state
• Not good for SEO ⇒ Since the HTML built from the server is not including the data from the API

SSG & ISR flow

Static-Site Generation (SSG)

How it works:

• The build and fetch data process happened at the same time ⇒ getStaticProps() function (Next 12) or fetch() function (it’s set as default in Next 13) is running at build time
• After the HTML + JSON is built (the data from API is included), it will be sent to the server
• When the user (browser) requests, the server will send the HTML + JSON file, so the user doesn’t need to wait (no loading!)

Use-case:

• If your site data is definite (fetch once and that’s it)
• Example: site for Al-Qur’an, logs/history data, or old archived documents — which won’t be changed no matter what

Pros

• Overall the fastest method
• No loading
• The burden is not too big for the server
• Good for SEO

Cons

• Don’t have the trigger to update the data from API (fetch one and that’s it) unless it’s redeployed
• Can’t be used as personalized content ⇒ Because this method doesn’t have any way to update the built HTML file from the server (so whenever the user requests, it will remain the same)

Incremental Static Regeneration (ISR)

How it works:

• Pretty much the same with SSG, but with the capability to update the data
• If you set the revalidated data on the getStaticProps() function (Next 12) or fetch(‘https://.../data', { next: { revalidate: 10 } }); (Next 13), the server will revalidate the data from the API and see whether there’s any change
• If there’s any update from the API (DB), then the built HTML file will be updated (the new one will overwrite the current one)
• But, it will only be updated after the set time in revalidate props time is passed
  — Example: If you set revalidate: 10 ⇒ It will do the revalidation and update the HTML after 10 seconds are passed

Use-case:

• Best practice for most static sites that don’t need a real-time update

Pros

• Basically, it’s SSG (fast + good for SEO!) but with an additional tweak to be able to update the site’s data

Cons

• Can’t be used as personalized content
• Can’t be used if you have a real-time feature on your site

Conclusion

If your site (or site-content) conditions are:

• Doesn’t have personalized content, doesn’t need to update the site data, and SEO is an important factor-> SSG
• Doesn’t have personalized content, needs to update the site data (non-real-time), and SEO is an important factor-> ISR
• Need to update the data frequently, has personalized content, and SEO is an important factor -> SSR
• Need to update the data frequently, has personalized content, and SEO is not an important factor -> CSR

Personalized means the data is unique for each client, for example -> data in the profile page, user’s name in the navbar, etc

For your information, you can combine these rendering strategies to achieve the most efficient result for your site.

Thank you for reading, any kind of feedback will be appreciated 🙏🏻