Incremental Static Regeneration: a Great Way to Reduce Websites’ Build Time, Costs & Workload

In one of our blog posts, we previously discussed the Jamstack approach that essentially allows us to enjoy the benefits of pre-rendered static pages, like speed and security, without giving up on interactivity.

Those static pages are sent to a content delivery network, which makes them fully available as static files in a matter of seconds thanks to the export async function getStaticProps.

But there is a crucial problem: static sites, while easy to load and provide great user experience with, take some time to build – if you have to add thousands of products to your online store, it will take forever.

This is a vital issue for large-scale shops and other enterprises, which means they need a more flexible solution – and here incremental static regeneration (ISR) may come in handy.

ISR is a relatively new feature of Next.js, which is a simple and minimalist JS framework, and one of the leading platforms for building React apps.

In one sentence, this method allows us to update content without the need to redeploy the page, which translates to better performance and security, as well as a shorter building time. Let’s dive into the details!

From this article, you will learn:

• What the methods of serving static content pages are
• What the differences between the classic approaches to static generation – SSG and SSR – are
• How incremental static regeneration works and why it’s being used
• What the options in ISR are
• How the mixed approach works

How do you serve a static page? The classic approaches

There are two “classic” approaches, namely static site generation and server-side rendering, and of course both have their pros and cons. Let’s take a look!

Static site generation

This method is possible thanks to so-called static site generators – these are pieces of software enabling the creation of pages from templates, components, and a specific content source. You feed them with content and the generator prepares a ready-to-use website.

The previously generated pages are pre-rendered during the build time and, in order to add new content or components, you have to rebuild the whole site again from the scratch.

Well, to be more precise, it’s not you in person who’d need to build it – it’s the static site generator’s task that will be processed in the background, if it’s set up well.

Needless to say, this approach only suits websites where content isn’t changed so often (farawell, news websites!), otherwise the process would take forever. It may also be problematic when your application is very big. But very, very big.

However, among the advantages of static-generated sites we can list great speed, easy deployment, version control, and enhanced security (because there is no database that could fall victim to an attack).

Server-side rendering

With server side rendering, you don’t render pages in the browser, but directly on a server, and then pass them to the browser. They are not generated during the build time, but on each user’s request.

Thanks to this approach, it is easy to change the code without having to build the whole app again and again.

This approach is good for complex apps with extensive user interaction, where content is changing quite often or it is tailored to the specific needs of specific (groups of) users – such as big ecommerce stores or social media platforms.

Those websites, however, are slightly slower to load, because the app is rendered twice – on the server and on the client’s side – and this can make a big difference.

They are also less secure than in the case of SSG, and need more powerful (and costly) servers.

Incremental static regeneration – a perfect hybrid?

As we have said, in the case of SSG you have to pre-render all the pages, which consumes a lot of time, especially when the content is often changing.

With SSR, however, each page also has to be rendered each time a user makes a request, which means that the same content is generated over and over again, which is a waste of resources when the content is mainly static.

Take the “About us” page, for example. In most cases, it’s the very same page that is being shown to every user, no matter their location or browser used.

This is where ISR comes into play. It is best described as a hybrid between SSG and SSR. It is also a relatively new feature available in Next.js, so how does it work, exactly?

In the case of incremental static regeneration, a static page is being generated during the first request (of any user) on a specific page – and not during the build.

The user most often gets a fallback page for the time of waiting, which appears immediately, and, once the data is resolved, they are served the final page.

This method reduces the build time, all while keeping the page generated for future visitors who may enjoy shorter response time.

In Next.js, we can also set the time when this initial page should be generated once again (regenerated).

So, ISR enables websites to use a “one page at a time” approach without having to rebuild the whole site from scratch. You can keep all the benefits of static pages, even on a website that has millions of them (and counting). This strategy is called “stale-while-revalidate”.

This means incremental static regeneration will be perfectly suitable for big eCommerce websites with hundreds of thousands of pages. With static site generators, they would have been built within hours.

Main benefits of ISR

There are some benefits that differentiate incremental static regeneration from static site generation and server-side rendering.

One of them is improved performance – which means that users are more likely to visit the website, and this helps achieve business goals.

Business owners and users can also enjoy better security than in the case of SSR, because rendering functions are only being used to generate pages and don’t have direct access to requests made by users.

Finally, and very importantly, the application can be built in a shorter period, especially when it is big or growing quickly.

ISR options

There are a few different options you can choose from while using ISR. Let’s take a closer look!

Automatic revalidation

This is the default option thanks to which the pages will be regenerated after a fixed interval, which can be chosen by the developer. There is no need for additional configuration, as the whole process is automated.

The drawback of this solution is that users that enter the site in this interval might not see the latest version of the cached page. Obviously, the more often the content of the website changes, the shorter this interval should be.

Anyway, it is useful when it comes to pages that are frequently updated with new content.

On-demand revalidation

As the name indicates, a static page is regenerated on demand. The pages are revalidated the moment new or changed content is updated into the CMS and published. In this case, the user always sees the latest version.

It is reasonable to use this solution on pages where the content only updates from time to time, which makes it easier to manage the resource consumption.

The mixed approach to serving static pages

It’s worth adding that you can connect the above options. Pages may be regenerated both on demand and additionally – for the sake of safety – every 60 seconds, or via another time interval.

And you have full freedom in choosing which pages should be revalidated according to which method and what the time interval should be for each.

This way, you can set a longer interval for pages that are of less importance, or their content doesn’t change very often, while also choosing the on-demand approach for pages of crucial importance.

You can also incorporate different rendering approaches to different parts of your website – for example, you can choose SSG for pages with content that almost never changes, like the privacy policy in an online store.

The wrap-up

Incremental static regeneration is a fairly new way to update static pages, used mainly in the wider Jamstack approach, which is based on static sites with dynamically generated content (each of them is a separate static file).

It allows for the better management of resources, both in the context of performance, and build time. It will be gaining popularity as websites expand and become more and more rich in content. As we had stated in the title, ISR is a key to reducing websites’ costs and workload.

If you’d like to discuss how we can help you build an optimized app for you, just contact us!