ISR (Incremental Static Regeneration) for Your Website

ISR (Incremental Static Regeneration) for Your Website

We implement Incremental Static Regeneration (ISR) — an approach that combines the speed of static sites with the freshness of SSR. ISR updates individual pages without a full rebuild: cached HTML is served in milliseconds, and stale versions regenerate in the background. Unlike SSR, the server isn't loaded on every request; TTFB drops by 5–10×. Ideal for e-commerce stores, blogs, and portals with frequently changing content.

A typical problem: content managers update products, but visitors see old data. ISR solves this — after a CMS publish, the page regenerates by tag within seconds. Users never wait, and search engines index fresh versions. On one project with 10,000 products, we cut TTFB from 400ms to 15ms and server load dropped by 85%.

Why ISR Is Better Than SSR for High-Load Projects

The classic model is Stale-While-Revalidate at the page level:

1. First request to a page — server-side render, cache the HTML.
2. Subsequent requests within TTL — served from cache, response <10ms.
3. Request after TTL expiry — serve stale cache (user doesn't wait), trigger background regeneration.
4. Next request — fresh HTML from updated cache.

Result: TTFB as low as static, content freshness like SSR. ISR serves cache in <10ms and reduces server load by 70–90%. Meanwhile, content remains fresh within TTL. For projects with thousands of pages, ISR consumes almost no server resources during peaks.

How to Set Up On-Demand Revalidation

TTL-based caching isn't enough when you need to refresh a page immediately after a CMS change. For that, use on-demand revalidation via an API:

// app/api/revalidate/route.ts import { revalidateTag, revalidatePath } from 'next/cache'; import { NextRequest, NextResponse } from 'next/server'; export async function POST(request: NextRequest) { const secret = request.headers.get('x-revalidate-secret'); if (secret !== process.env.REVALIDATE_SECRET) { return NextResponse.json({ error: 'Unauthorized' }, { status: 401 }); } const { tag, path } = await request.json(); if (tag) revalidateTag(tag); if (path) revalidatePath(path); return NextResponse.json({ revalidated: true }); } 

A webhook from the CMS calls this endpoint on publish. We integrate with Contentful, Strapi, WordPress, and other systems.

Implementation in Next.js App Router and Nuxt 3

Next.js

// app/products/[id]/page.tsx interface Props { params: { id: string }; } async function getProduct(id: string) { const res = await fetch(`https://api.example.com/products/${id}`, { next: { revalidate: 300, tags: [`product-${id}`] }, }); if (!res.ok) return null; return res.json(); } export default async function ProductPage({ params }: Props) { const product = await getProduct(params.id); if (!product) notFound(); return <ProductView product={product} />; } export async function generateStaticParams() { const popularProducts = await fetch('https://api.example.com/products?popular=true&limit=100') .then(r => r.json()); return popularProducts.map(({ id }) => ({ id })); } 

Pages from generateStaticParams are generated at build time. Others are generated on first request and then revalidated by TTL.

Nuxt 3 — a page uses useFetch with a key, and the server handler is wrapped with cachedEventHandler:

// server/api/products/[id].ts export default cachedEventHandler( async (event) => { const id = getRouterParam(event, 'id'); return await $fetch(`https://api.example.com/products/${id}`); }, { maxAge: 300, staleMaxAge: 3600, name: 'product', getKey: (event) => `product-${event.context.params.id}`, } ); 

Comparison: SSG vs SSR vs ISR

Caching Strategies

ISR lets you assign different TTLs for different page types:

For distributed deployments, we use an external cache store like Redis.

// next.config.ts import type { NextConfig } from 'next'; const nextConfig: NextConfig = { cacheHandler: process.env.NODE_ENV === 'production' ? require.resolve('./cache-handler.js') : undefined, cacheMaxMemorySize: 0, }; // cache-handler.js const redis = require('ioredis'); const client = new redis(process.env.REDIS_URL); module.exports = class CacheHandler { async get(key) { const data = await client.get(key); return data ? JSON.parse(data) : null; } async set(key, data, ctx) { const ttl = ctx.revalidate || 3600; await client.setex(key, ttl, JSON.stringify({ value: data, lastModified: Date.now() })); } async revalidateTag(tag) { const keys = await client.smembers(`tag:${tag}`); if (keys.length) await client.del(...keys); await client.del(`tag:${tag}`); } }; 

Monitoring and Debugging

Track in production: cache hit rate, revalidation duration, stale responses. We set up metrics in Grafana. For example, adding an x-cache-time header via middleware helps analyze cache freshness.

What's Included in the Work

• Audit current architecture and performance.
• Design caching strategy with TTL selection.
• Implement ISR on the chosen framework (Next.js, Nuxt 3, or custom solution).
• Integrate on-demand revalidation via CMS webhook.
• Set up distributed cache (Redis) if needed.
• Configure CI/CD with cache warming after deployment.
• Monitor and optimize based on metrics.
• Documentation and team training.
• Support during warranty period.

Implementation Process and Timelines

Phases:

1. Architecture analysis and caching strategy definition (1–2 weeks).
2. ISR setup on chosen framework (1–3 weeks).
3. Integration with CMS via webhook for on-demand revalidation (1 week).
4. Distributed cache (Redis) setup if required (1 week).
5. CI/CD configuration with cache warming (3–5 days).
6. Monitoring and optimization based on metrics (1–2 weeks).

Timelines: 2 to 6 weeks depending on complexity. Pricing is project-based.

Our engineers have worked with Next.js and Nuxt for over 7 years; we've implemented ISR on 50+ projects, including high-load e-commerce stores. We guarantee stable performance and transparent support. Get a consultation on stack selection and caching strategy — contact us for a project evaluation.

Next.js ISR documentation