Back to BlogFebruary 2, 2026

Next.js, ISR, and Why Your CMS Barely Needs to Break a Sweat

Next.js
Web Development
Sanity
Performance

The Evolution of Rendering on the Web

For the longest time, web rendering was simple. The server generated HTML, sent it to the browser, done. Then Single Page Applications came along — React, Angular, Vue — and shifted everything to the client. The browser received a nearly empty HTML shell and JavaScript did the rest. Great for interactivity, terrible for SEO, initial load times, and accessibility.

Server Side Rendering (SSR) brought the best of both worlds: the server renders the full HTML on each request, delivers a fast initial page, and React hydrates it on the client for interactivity. But SSR has a cost — every single page visit triggers a server-side render. For content that barely changes, that's wasteful.

Enter ISR — The Sweet Spot

Incremental Static Regeneration is where Next.js truly shines. With ISR, pages are statically generated at build time — just like a classic static site. But here's the key: you define a revalidate interval, and Next.js will regenerate the page in the background after that time has passed. The user always gets a fast, cached response. The regeneration happens invisibly.

This gives you the performance of a static site with the flexibility of a dynamic one. No spinning servers on every request. No stale content forever. It just works.

Why This Matters for Headless CMS Users

If you're using a headless CMS like Sanity, Contentful, or Strapi — especially on a free tier — API rate limits are a real concern. Sanity's free plan, for example, includes a generous but finite number of API requests per month. If every page visit triggers a fresh GROQ query, those requests add up fast. A blog with moderate traffic can easily burn through the free quota.

With ISR and a revalidate of 3600 seconds, a page that gets 10,000 visits per hour still only makes one API call to Sanity. The other 9,999 visitors get the cached static page. Your CMS barely notices.

On-Demand Revalidation — The Final Piece

Time-based revalidation is great, but what about instant updates? If you publish a new blog post, you don't want to wait up to an hour for it to appear. That's where on-demand revalidation via webhooks comes in.

You set up a simple API route in your Next.js app:

// /api/revalidate
export async function POST(request: Request) {
const secret = request.headers.get('x-webhook-secret');
if (secret !== process.env.REVALIDATION_SECRET) {
return new Response('Unauthorized', { status: 401 });
}
// Revalidate the affected paths
revalidatePath('/blog');
return Response.json({ revalidated: true });
}

Then you configure Sanity (or any CMS) to call this endpoint whenever content changes. The result: pages are cached indefinitely, API calls stay minimal, and updates go live within seconds of hitting "Publish." You get the best of all worlds — static performance, dynamic freshness, and almost zero API overhead.

The Practical Impact

On this very site, every page uses ISR with a one-hour revalidate window. A Sanity webhook triggers on-demand revalidation when content changes. The effect: Sanity's API gets called a handful of times per day instead of thousands. The free tier is more than enough — and the site loads instantly for every visitor.

For anyone building content-driven sites on a budget, the combination of Next.js ISR and CMS webhooks isn't just a nice optimization. It's the architecture that makes the free tier genuinely viable for production.

Next.js, ISR, and Why Your CMS Barely Needs to Break a Sweat - Image 1