Next.js has skyrocketed in popularity due to its versatile and flexible features that allow web developers to create amazing websites and apps. But one feature of Next.js that is often less utilized is incremental static regeneration (ISR). It’s an excellent feature to implement when you need to overcome the challenges that static site generation (SSG) can present while keeping its performance benefits. So, in this post, we’re going to explain everything you need to know about ISR as well as its benefits so you know when to reach for it and how it can help you.
Incremental static regeneration (ISR) explained
ISR is one of the rendering methods that Next.js offers to developers alongside SSG, SSR, and CSR. Vercel describes it as a rendering method that “enables you to use static generation on a per-page basis, without needing to rebuild the entire site.” This means that you can rebuild an individual page without regenerating all pages within your build. With this feature, we can get the same great page loading speeds and user experience of static pages rendered with SSG without the increased build times and data frequency issues it can create, as we’ll explore later on.
This subtle difference between ISR and SSG is what makes it stand out as a rendering method; ISR offers us a potential bridge between the great performance of SSG and something closer to the data accuracy of SSR, which can help us effectively scale to millions of pages and users without suffering the increased server-load of SSR or the inflated build times of SSG.
That’s cool, but you may be wondering: how does ISR work? ISR works by statically generating pages (like SSG) in response to users’ requests (like SSR). These generated pages are then stored in a cache for future users to receive. This cache is what gives us the same performance as SSG, while the ability to update and rebuild pages individually gives us something closer to the data accuracy of SSR mentioned above.
Overall, there are two ways you can use ISR in your project: standard ISR or on-demand ISR.
Standard ISR
With standard ISR, developers are able to control how often a page is regenerated, and the cache for a page is invalidated by using the revalidate property in getStaticProps. We can pass a number to revalidate (in seconds) to control how long Next.js waits before regenerating the page on the next request.
So, as an example, if we had the revalidate prop set to 10, the first request to the page would trigger the initial static generation of the page. Then for 10 seconds after that initial page generation, any requests would be given the original (cached) page. After that 10-second window has elapsed, the next request for the page would still see that cached page, but it would now be marked as stale in the background causing Next.js to trigger a regeneration of the page.
If the page regeneration is successful, the cached page is then updated to the new one, and future requests would receive that for the revalidate time period. If the regeneration fails, the old stale page continues to be displayed.
Take a look at how to implement standard incremental static generation.
On-demand ISR
On-demand ISR is slightly different from standard ISR in that it allows developers to manually purge the cache used for ISR and regenerate the pages by calling the revalidate() function and passing it a path to revalidate.
This means we could implement some custom logic to trigger the regeneration of the page that isn’t just time-related. For example, you could use a webhook to trigger the regeneration of a page when it’s updated without needing a full rebuild of all pages.
So, when it comes to the two types of ISR, the key difference between them is how the cache is invalidated and, therefore, the pages are regenerated. If you’re okay with a time-based approach standard ISR is probably best, but if you need custom logic to trigger regeneration, then on-demand would be better.
Take a look at how to implement on-demand ISR.
Benefits of ISR
Understanding the benefits that ISR can bring is essential to understanding whether ISR is right for your project. That way, you can make a clear decision about whether these benefits are worth any challenges or drawbacks for your project.
Faster page load times with recent data
After an ISR page has been generated for the first time, it’s just a normal, statically generated page, which means you get the same fast load times and page speeds as you would with an SSG page.
But, what differs between ISR and SSG is the fact that ISR pages can have their data updated throughout the life of the deployment without a full redeploy. This means if you want to show newer data after the original build has been completed, ISR-rendered pages will update to show the new data a lot faster than SSG pages, which would require an entirely new build of the website.
Reduced build times
ISR pages don’t need to be generated at build time; they just need to be generated when users request them for the first time (or when they’re revalidated). This means the build and deploy times can be reduced greatly, allowing for faster deployments. This is ideal for websites that need to deploy and update content quickly, such as news websites, for example.
Scalability
Finally, ISR deployments are more scalable in some cases than SSG or SSR. If you wanted to use SSG with a high number of pages, the build time could become unmanageable. Or, if you wanted to use SSR with high amounts of traffic, you could risk overrunning the server with requests and causing crashes or timeouts due to the server not being able to keep up with the traffic.
ISR allows us to strike a middle ground between SSR and SSG by using static pages and periodically rebuilding them to fetch the latest data. This means less server load at runtime as well as shorter build times.
When is ISR helpful?
Now that we understand more about ISR, let’s take a look at how it’s helpful and some examples of how you can use it.
ISR is a great tool to reach for if you want to leverage the benefits of statically generated pages but also have a large number of pages. This is because the duration of your application builds and deployments will linearly increase with the more pages you add. ISR allows us to cut down on those times by selectively choosing which pages we want to render at build time and allowing the rest of them to render when users request them.
ISR example
A good example of the above benefits in practice would be using ISR on a very large blog. Blogs can easily reach thousands of pages, and statically building those with SSG can really bloat your website build times. This problem is exacerbated when a blog is publishing regularly and adding new pages because it means more pages to generate and more time to wait for builds, increasing the delay in getting content published on a regular basis.
However, standard ISR could cut down on these build times by letting the pages be statically generated when the user requests them for the first time instead of during the build. Or, with on-demand ISR, you could use a webhook in a headless product like Prismic to trigger rebuilds when posts are updated.
ISR vs. SSG and SSR
Still not sure which rendering method is best for your project? Here’s how ISR stacks up against SSG and SSR.
SSG
SSG is a very powerful rendering method. Its only downsides are the potential for users to see stale or outdated data for a period of time and the long build times that it entails. But, if your use case isn’t significantly impacted by briefly outdated data or long build times, then the benefits of fast load times and better user experiences might be worth it. For instance, a small- to medium-sized blog or marketing website may not present issues that require the additional setup of ISR.
However, as your website grows along with your build times, it may be worth looking into transitioning to ISR on some or all of your pages and using it selectively.
SSR
When comparing ISR to SSR, there are some nuances to consider. SSR is an excellent rendering choice in use cases where data freshness is critical, and other factors, such as SEO priorities and initial load times make client-side rendering a less beneficial choice. That’s because every request for a page gets the latest data from the server before it’s sent back to the user. Meanwhile, with ISR, there is the potential that users will be shown cached and stale content while the page is regenerating in the background.
So, to take a high-traffic e-commerce site as an example, it’s critical that information like stock levels and prices are accurate for every user. In this case, the short period of time where the data goes stale with ISR could have a negative impact, and you should instead reach for SSR.
However, where data freshness is somewhat important but not as critical, you can reach for ISR to get the benefits of SSG while keeping your data up-to-date without long build times. For example, a news website might benefit from on-demand ISR because the updates to their content are important (and frequent, as developing news unfolds), but a brief moment of data staleness won’t significantly impact the user’s experience. In this case, the benefits of faster page loads and shorter build times are worth the extra configuration.
Getting started with ISR
We’ve covered everything you need to understand about ISR as well as where you might want to use it. Now, if you’ve determined it’s the right solution for you, it’s time to get started with it. Next.js has a fantastic guide on getting started with both standard and on-demand ISR.
Closing thoughts
As with many things in the web development space, whether or not ISR is the best option for you depends on many factors that are individual to your project. But, the saving grace is that Next.js offers all of these features and makes it relatively easy to switch between them, so you don’t need to commit to one decision forever today. You could try ISR for a few days and see if it benefits you, or you could omit it today and wait for a time when it’s clear you need it to solve a problem.
