What is Incremental Static Regeneration and Server-side Rendering in Next.js?

What is Incremental Static Regeneration and Server-side Rendering in Next.js?

Published 8th, November, 2022

4 min read

Next.js, although framework of React.js has been making waves since the last few in the world of web development for its complexity which sets it apart from other JavaScript derived programming and scripting languages. Next.js has set new standards by introducing features that are tailor made to certain common issues faced by front-end developers. ISR, short for Incremental Static Regeneration is what it says in its name; it regenerates your website’s static files without having to make massive changes.

When old rivals combine forces, ISR is born!

The ISR feature is a hybrid of two old features required for generating and rendering web page; the SSG or Static Site Generation and the SSR, the Server-Side Rendering. They stand apart each other at a time when the HTML page gets generated. Simply, Static Site Generation implements when the HTML gets generated during the build time. The pre-rendering feature of the SSG helps making it cache-able and lead to fast delivery.

According to Vercel, the team behind developing Next.js, it is recommended that SSG is the way to go as a default mode rather than an explicit choice. SSG, going by its characteristics, suits better to blogs, e-commerce websites, documentations and professional portfolios.

Static Server Rendering responds to individual request to generate a page’s HTML. SSR is said to be more flexible than the other since the HTML can be manipulated without having to build the application each time. Hence, websites/apps that has a continuously changing data SSR is the way to go, and not SSG.

However, it would be apt if we compare SSR and its progeny, the ISR and steer the discussion in that direction, since both of them are powerful.

A rule of thumb that separates both is that in case of SSR, a request is read and the resource is fetched for the end-user. This may take time for various technical reasons. ISR, on the other hand, serves the page immediately when the request is made and in case if there is a delay, a ‘fallback page’ is rendered. We’ll talk more about that later in this discussion, after we are done with SSR.

Rapid rendering with server-side rendering!

The first and the most obvious benefit of server-side rendering is that it loads the pages faster, and thus contributing to a better end-user experience. This feature is more important for web apps such as online travel booking, online purchases, e-commerce or the education domain. This shows that SSR is an ideal business application development choice for income generating web apps.

Besides, SSR is also a good SEO helper. For those who might not know; Search Engine Optimization is all about data and how it is rendered. SEO holds in high regard to web pages online that are either top knowledge and content authority for topics or web pages related to corporate/government bodies.

This helps the web crawlers to crawl and index the web page for relevant content. A web page doesn’t need to have to load the whole content in one go. Instead loading the data can be prioritized whilst HTML taking its own time to load.

Faster web page loading leads to web browsers correctly indexing your website.

And then slow internet connection in places existing in a time warp acts as a wet blanket on this miracle, right? Nope! Server-side page rendering enables efficient page loading for old devices or super slow internet speeds.

What comes up,  also goes down!

Don’t worry, it’s not going to be dense. SSR still kicks arse!

But it might burn a hole in your pocket to maintain and host such a high-performance website/webapp. To add into that, SSR also consumes a lot of speed and memory of the machine(s) on which is hosted.

When SSR renders a largely static page, it is at its peak efficiency, but bring a more dynamic page to the test and the load times will increase caused due to request-to-response bottleneck.

In case if your application is going to interact with other page/app, server-side rendering might not be compatible if a third-party JavaScript application is used in the development stack.

Alright, it has its holes too, but we can make a good judgment and use SSR only in case if we are developing complex dynamic applications.

Back to the future

We’ll pick up from where we left. It is so, that when it takes a lot of time for a web page to load, ISR will load a fallback page. The fallback page is an engagement agent that shows the front-end interface, in the meanwhile when the data and design are being fetched. These ‘engagement agents’ are officially known as skeleton pages.

And once the fetched data is received, the page is cached and people visiting here one after the other will be accessed to a cached version of the web page. Developers can also make certain settings for re-validating and updating the page.

This strategy to cache a web page before re-validation occurs, has an official term named, “stale-while-revalidate”. This method could have been used more than a decade ago, but wasn’t widely available(must be a ‘cutting-edge’ web development tech). ISR from Next.js has just made it more mainstream for ordinary developers.

And then?

Do you aspire to become a highly-paid front-end developer? Learning React.js and Next.js will be good choice(but only if you have at least some experience with JavaScript. You are at an advantage if you are fresher, for the reason that if you know these technologies, chances are high that you’ll be chosen for the role.

As a side note, we suggest you build a typical web application like the ones stated above; e-commerce, education, blogs etc. with Next.js in the front-end as a side project and see for yourself how it performs.


  1. logrocket
  2. heavy
  3. next.js