Introduction
The first thing you wrestle with when adopting ISR is deciding when the cache (the pre-built page) should be rebuilt. Set the interval too short and pages are rebuilt so often that the speed advantage fades; set it too long and stale information keeps showing. So where is the sweet spot?
This article explains how to think about revalidate, the setting that controls this balance, along with On-Demand ISR for updates that can't wait, and the Webhook integration that carries product updates to the site automatically.
Setting Cache Lifespan with revalidate
Just Declare "This Pre-Built Page Is Valid for 60 Seconds"
revalidate is a per-page setting that specifies, in seconds, how long a pre-built page stays valid. Set it to 60, and the cached page is served as-is for 60 seconds; the first visit after the period expires triggers a rebuild in the background.
It sounds sophisticated, but the actual implementation is a single number per page. Telling an AI agent (AI-powered development support) "make product pages refresh every 60 seconds" and letting it wire up the setting is a perfectly workable way to proceed.
Choosing Intervals Based on Page Characteristics
There's no need to give every page the same interval. Pages differ in how urgently they need updates, so lifespans should differ too.
- Product detail pages: Set short, prioritizing inventory and price accuracy
- Collection (listing) pages: Set medium, matched to how often new products are added
- Homepage: Can be long if it rarely changes
"The more a page changes, the shorter its lifespan; the less it changes, the longer." That's the whole rule of thumb.
When in Doubt, Start Long and Shorten as Needed
There's no need to land on perfect numbers from day one. A more realistic approach is to shorten the interval only for pages where updates feel slow in actual operation. Shorter intervals mean more rebuilds and more API requests, so leaving pages long when there's no particular reason to shorten them is the safe default. revalidate can be changed at any time, so the working order is: launch first, observe, then adjust.
On-Demand ISR — Updating Without Waiting for Expiry
What Happens with Regular ISR Alone
With revalidate alone, stale content keeps showing until the period runs out. Suppose you spot a pricing mistake and fix it in the admin panel right away — the wrong price still shows until the cache expires. Automatic refresh is fine for routine updates, but it falls short when something must be corrected now.
Invalidating the Cache with an External Signal
That's where On-Demand ISR comes in. It's a mechanism for sending a signal from outside — "this pre-built page is stale, please discard it" — to invalidate the cache. You prepare a receiving window on the Next.js side (an API Route — a reception desk for external requests) and call it whenever needed. The signaled page is rebuilt with the latest content on its next visit.
Reflecting Product Updates Automatically with Webhooks
How an Admin-Panel Update Reaches the Site
Sending On-Demand ISR signals by hand isn't realistic, so they're automated with webhooks (a mechanism that sends automatic notifications when something happens). The flow looks like this:
- Product information is updated in the admin panel
- The update event is sent to Next.js via Webhook
- The receiving window (API Route) invalidates the cache for the affected pages
- On the next user visit, the page is rebuilt with the latest data
All the staff member does is update the admin panel as usual. Everything after that is automatic.
How Operations Got Easier
Once this integration was in place, the cycle of "I updated it, why isn't it showing?" disappeared. Nobody files a request to an engineer or rebuilds the whole site just to push a change live. Pages are served fast from cache in normal times, and refreshed immediately when something changes — neither operational effort nor loading speed gets sacrificed.
Architecture
While the cache is valid, the pre-built page is simply returned — the fastest path.
Even after expiry, the old pre-built page is served first while a new one is built behind the scenes, so users never wait.
A product-update notification discards the stale page, and the next visit swaps in the latest version.
Summary
The standard way to run ISR is a two-layer setup: revalidate decides the automatic refresh interval, and urgent changes go through Webhook-triggered On-Demand ISR. Choose lifespans that match each page's nature, and reserve the signal for updates that truly can't wait. This combination delivers fast loading and fresh data without strain.