Introduction
If you run an EC site, you may find yourself caught between two complaints: "pages load too slowly" and "product information is out of date." Freeze pages for speed and updates lag behind; always serve fresh data and pages get heavy. Helping one side tends to hurt the other.
This article explains ISR, a feature of Next.js (a framework that serves as the foundation for building websites), in a way that makes sense even if you're not an engineer. By the end, you should be able to judge what ISR actually does for you and whether it fits your site.
What ISR Is
In One Phrase: "Pre-Build, Then Auto-Refresh"
ISR (Incremental Static Regeneration) is a feature provided by Next.js. The official translation of the name is a mouthful, and you don't need to memorize it. The mental picture is simple: pages are prepared in advance, and after a set amount of time they are automatically rebuilt. Users always receive a finished page instantly, while behind the scenes the content is refreshed at the interval you choose. Speed and freshness, handled by one mechanism.
One Word Worth Remembering: "Cache"
Discussions of this mechanism keep coming back to the word "cache." Understanding it as "the place where pre-built pages are kept" is plenty. In ISR terms, "returning the cache" means handing over the pre-built page, and "invalidating the cache" means discarding a stale one. With just this one word under your belt, ISR explanations become far easier to follow. Put another way, designing with ISR is really the act of deciding how long a cache stays valid and when it gets thrown away.
Why EC Sites Need It
Product pages on an EC site change daily — inventory and prices move — yet they rarely need second-by-second accuracy. At the same time, catalogs often run to hundreds or thousands of pages, and the loading speed of each one directly affects bounce rates and sales. "Pages that update fairly often, in large numbers, that must load fast" — that requirement happens to be exactly what ISR is good at.
How ISR Differs from Other Approaches
There are three main ways to deliver web pages to users. Looking at them in order makes ISR's position clear.
SSG — Pre-Building Every Page in Advance
With SSG (Static Site Generation), every page is built as a finished product before the site goes live. Loading is very fast, but changing even one product requires rebuilding the whole site. For EC sites with large catalogs, that rebuild can take tens of minutes, so every update means waiting.
SSR — Building on the Spot for Every Visit
With SSR (Server-Side Rendering), the server assembles the page from scratch every time a user opens it. You always see the latest data, but assembly runs on every request, so there is a wait before the page appears. When traffic spikes, the server load grows with it.
ISR — Pre-Building, Then Refreshing at a Set Interval
ISR combines the strengths of both. Pages are pre-built, then automatically rebuilt at an interval you decide (a setting called revalidate). Users get the fast pre-built page while fresh content is swapped in behind the scenes. You keep SSG's speed without giving up SSR's freshness.
Always up to date, but assembly runs on every request and users wait for the page to appear
Serves the pre-built page instantly while rebuilding periodically in the background. Fast and fresh at once
In one sentence, ISR means "stop building on every visit — hand out the pre-built page and refresh it behind the scenes."
Where ISR Fits — and Where It Doesn't
A Good Fit: Pages That Update at a Moderate Pace
ISR shines on pages like these:
- EC product pages: Inventory and prices change, but to-the-second accuracy isn't required
- Blogs and announcements: New posts are added regularly, but existing ones rarely change
- Corporate sites: Information is updated periodically, without real-time needs
What they share is the trait of "updated, but not urgent by the second." A large share of the web falls into this category.
A Poor Fit: Pages That Must Always Be Current
Conversely, ISR is not suited to chat conversations or stock tickers, where real-time display is the whole point. Because pages are pre-built, a gap of seconds to minutes is unavoidable. In practice, EC sites mix approaches: product pages use ISR, while cart contents and logged-in account data are fetched in real time.
Summary
ISR is the Next.js mechanism that delivers both fast loading and fresh data. It keeps the speed of pre-built pages while refreshing their content automatically, which suits EC sites that need to serve many frequently-updated pages quickly.
How much difference it actually makes, and what happens under the hood, are covered in the next two articles.