Incremental Static Regeneration (ISR) is a significant extension of static generation, first introduced in the Next.js ecosystem. It bridges the gap between static generation and server-side rendering, combining the strengths of both approaches to solve common problems in modern web development.
How ISR works
ISR extends the idea of static generation by adding selective regeneration of pages. Unlike classic static site generation, where every page is generated at build time, ISR takes a more flexible approach. The system can generate static pages on demand at the first request, while keeping a "stale" version of the page available as it is regenerated. This removes the need for a full rebuild to update specific pages, and it also lets you set custom caching strategies for each route.
Revalidation strategies
ISR offers two main approaches to revalidating content: time-based and on-demand.
Time-based revalidation is the simplest to implement: you specify an interval after which the page may be regenerated. Note that regeneration does not happen automatically when the time runs out, but only when the page actually receives a new visit. This saves resources, because pages nobody visits are never regenerated.
On-demand revalidation gives you more granular control, letting you trigger regeneration when you need it. A common use case is integration with CMS webhooks: when content is updated in the CMS, it can call a specific API route in Next.js that starts the revalidation. This is particularly useful for content that needs immediate updates, such as news, sports results or product inventory.
A real use case: an e-commerce site with 100,000 products
Consider an e-commerce site with 100,000 products, where each product has its own page with details, prices and availability that are updated frequently throughout the day.
Let's look at the three possible implementations:
With a full static approach, every build would have to generate all the product pages, resulting in very long build times and high compute costs. Every price or availability change would require a complete new build, making it impractical to keep data up to date in real time. Performance for the end user would be excellent in terms of TTFB (Time to First Byte), but at the expense of data freshness.
With a full dynamic approach, every request would be processed by the server. Pages would always be up to date, but response times would vary with server load and latency would be higher than with the static solution. Costs would scale linearly with traffic, because compute resources are needed all the time.
With ISR, we can get the best of both approaches. At the initial deploy, we statically generate only the most visited pages. The other pages are generated at the first request and then cached. By setting an appropriate revalidate time, we make sure the data stays reasonably fresh. For products that need more frequent updates (e.g. live events or flash-sale products), we use on-demand revalidation.
This approach results in:
- A much shorter initial build time compared with full static
- Excellent performance for cached pages
- Slightly higher latency only for the first request to pages that are not cached yet
- Optimised compute costs compared with full dynamic
- Data that is always reasonably fresh, with no need for full rebuilds
- The benefits of server-side generation are kept, avoiding client-side data fetching and improving both SEO and the performance perceived by the user
What changes in the development pipeline
Adopting ISR in the development pipeline brings several concrete advantages. The first impact is on build times, which matters especially for sites with thousands of pages. This is possible because only the most important pages are generated statically in the initial build, while the generation of less visited pages is deferred to the first request.
One relevant technical aspect is handling updates with no downtime. The stale-while-revalidate pattern ensures that users always get an immediate response, while updates happen in the background without affecting the user experience. This translates into better use of resources, with the generation load smartly spread over time and caching based on actual access patterns.
Limitations
It is important to consider the current technical limits of ISR. Data consistency is one of the main challenges: ISR cannot guarantee real-time consistency, because there is always a chance of seeing stale data while a page is being regenerated. This is a necessary trade-off between content freshness and system performance.
Cache management adds further complexity, especially in multi-instance scenarios. Effective strategies for synchronising the cache and handling possible inconsistencies between different geographic regions call for careful architectural planning.
Provider support: Vercel and the others
ISR support varies between providers. Vercel supports On-Demand Revalidation, which gives granular control over the revalidation process and the ability to trigger specific updates when needed. Other providers, at the moment, mainly support time-based revalidation, which limits how much you can optimise and control the update process.
ISR on auto-scaling infrastructure
Implementing ISR in auto-scaling environments raises specific technical challenges only when you opt for custom hosting. On platforms like Vercel or AWS Amplify, these aspects are already handled internally by the platform. However, when you implement ISR on custom infrastructure, such as AWS ECS or other orchestrated container services, complexities emerge.
The main problem in these scenarios is cache memory conflicts: because Next.js keeps the ISR cache in memory, in an environment where instances are created and destroyed dynamically, cache management becomes complicated, with possible synchronisation problems and data loss during scaling.
For these custom setups, AWS EFS (Elastic File System) is one possible solution. This approach provides persistent storage shared across all instances, ensuring automatic storage scaling and consistency through the distributed filesystem. Integration with AWS backup and disaster recovery systems adds a further layer of safety to the architecture.
Best practices and conclusions
Implementing ISR requires a careful assessment of the specific usage patterns of your application. It is important to develop a route segmentation strategy that takes into account the different ways content gets updated. Revalidation times should reflect how often the content actually needs updating, balancing freshness and performance.
Monitoring is a fundamental technical aspect: tracking page generation times, monitoring cache usage and setting up alerting for revalidation failures are all necessary to keep the system efficient and reliable.
ISR offers a concrete technical solution for balancing performance and content freshness. The choice of infrastructure and provider significantly affects how you can implement it, and calls for a careful assessment of the trade-off between implementation complexity and the benefits you get. Adopting it requires a thorough understanding of its limitations and technical capabilities, so you can make informed choices based on the specific needs of the project.
What do you think of the advantages of implementing ISR? Want to know more? For opinions and thoughts, write to Lorenzo!
