ISR vs SSR vs SSG: When to Use What

Next.js gives you SSG, SSR, ISR, and now the app router with server components. Having options is great, but I've seen teams pick a strategy based on blog posts rather than their actual data and traffic patterns. The result is either stale content or unnecessary server load.

After shipping production apps using all three strategies at Mamaearth, CARS24, and Flipkart, I've developed a simple decision framework. It comes down to two questions: how frequently does the content change, and how important is freshness to the user?

Static Site Generation is the fastest option and the simplest to operate. If your content changes less than once a day and you can tolerate a deploy cycle for updates, SSG is the right choice.

I use SSG for marketing pages, documentation, and blog content. At Mamaearth, our landing pages were fully static — they changed maybe twice a month, and a five-minute build cycle was perfectly acceptable. The pages loaded in under 1 second on 3G, and our hosting costs were negligible.

The trap with SSG is trying to use it for content that changes more frequently than your build pipeline can handle. If you're running builds every 10 minutes to keep content fresh, you've outgrown SSG.

Incremental Static Regeneration was a revelation for our product pages at Mamaearth. We had thousands of product pages that changed multiple times a day — prices, stock status, reviews — but didn't need to be real-time accurate.

We set a revalidation interval of 60 seconds. This meant that at most, a user would see data that was one minute old. For an e-commerce catalog, this was perfectly acceptable. The first request after revalidation served stale content while regenerating in the background, so there was no latency penalty for the user.

The key insight with ISR is choosing the right revalidation interval. Too short and you're basically doing SSR with extra steps. Too long and your content is stale. We found that 60 seconds was the sweet spot for product pages, and 300 seconds was fine for category pages.

Server-Side Rendering makes sense when every request needs up-to-the-second data. At CARS24, our car detail pages had to show real-time availability — a car could be sold at any moment, and showing a sold car as available was a terrible user experience.

SSR comes with operational costs. Every page view is a server request, which means you need to provision for peak traffic, handle server failures gracefully, and optimize your data-fetching layer. At CARS24 we added a Redis cache with a 10-second TTL in front of our SSR pages as a compromise between freshness and server load.

My rule of thumb: if you're using SSR, you should be able to articulate why ISR with a short revalidation window isn't sufficient. If you can't, you probably don't need SSR.

With Next.js app router, server components introduce a new dimension. Components that fetch data on the server and send rendered HTML to the client can coexist with client components that handle interactivity. This lets you mix rendering strategies at the component level rather than the page level.

At Flipkart, we're using this hybrid approach for pages that have both static and dynamic sections. The product description is a server component that can be cached aggressively. The price, availability, and user-specific recommendations are client components that fetch fresh data. This gives us the performance of SSG for the bulk of the page with the freshness of client-side rendering where it matters.

The mental model shift is important: stop thinking about rendering strategy per page and start thinking about it per component. This is where the app router genuinely shines.